explore how to start Quarkus template

[ssala034]

With the start of GSoC, I now want to begin designing how to start the Quarkus template inside the generator project. I aim to just make the structure for where the Quarkus models and handlers will be and maybe add some mock

This issue serves as the foundation for setting up a mock application that reflects Quarkus microservice best practices, including integration with the Quarkus CLI. (Trying not to mimic the Spring boot approach to building an app). Will have the basis of the Quarkus template and can add more complexity to it there (i.e. protocol support, templated code for users) over time.

🎯 Objectives:

• Initialize a Quarkus project structure using the Quarkus CLI.
• Create mock modules for:
  • Command-line interface handling (using @Command)
  • Event model stubs
  • Basic message publisher and subscriber structure

Layout of project for future template code

• src/main/java – application logic

• src/test/java – unit tests

• src/main/resources – configuration (e.g., application.yml)

• Begin with one mock command (e.g., HelloCommand) for testing Quarkus CLI integration.

• Add basic unit test to verify CLI command output of HelloCommand.

• Ensure Quarkus Dev mode starts with the provided mock service.

Proposed structure: ''' packages/tempalte/quarkus-template/ ├── build.gradle ├── settings.gradle ├── src/ │ ├── main/ │ │ ├── java/ │ │ │ └── com/asyncapi/ │ │ │ ├── Application.java │ │ │ ├── cli/ │ │ │ │ └── HelloCommand.java │ │ │ ├── service/ │ │ │ │ └── MockPublisherService.java │ │ │ └── model/ │ │ │ └── EventMock.java │ │ └── resources/ │ │ └── application.properties │ └── test/ │ └── java/ │ └── com/asyncapi/ │ └── ApplicationTest.java ├── docker/ │ └── (later) ''''

Future Thoughts:

• Does it matter if I use gradle or maven for building my code. - Maven is used more widely. ( I am fine with either one)
• Any thoughts on best setting it up to easily use AsyncAPI generator later.

[derberg]

No opinion from my side on Quarkus itself and Java.

What I need to know is:

• quarkus capabilities, what protocols you want to support
• what is the intention of generated code? just client? or ?

for me most important is to place it in the right directory, following the standard we have at the moment. And identify the prerequisites we need before creating another template - we already have 3 templates for websocket, and basically, each is different already on feature level, so creating a new template following the current setup is not the best choice.

[ssala034]

For protocols, I will definitely be looking to implement kafka in the template. And websockets, seem great start off with as well. I was also looking to add ampq (rabbitmq) since it is also very common, but more so after I get the core protocols implemented first. Quarkus has the capabilities of supporting all three

I believe that it should just generate code that has the right models, publishers, operations. After looking at the Spring template, I think the model they generate should be what we provide also. We moodify some aspects with the Quarkus CLI (in terms of adding extensions)

For the structure, I was thinking that we should have a general quarkus-template directory, then just develop the protocols as in Websocket case (i.e in separate folder hierarchy). Then add in complexity to the quarkus-template, kinda like plugging in protocols to the Quarkus services. So we have a general hub for the Quarkus template and the other piece will be developed without needed to be dependent on it. Less coupled and more reusable.

[derberg]

spring template is old, not supporting v3 and also not using Modelina for models generation. For sure for new templates we should use the existing Models component that wraps modelina.

just remember the structure we follow at the moment in generator. We go away from old approach where one template can support multiple protocols. We ame direction, one template one protocol and one framework. And reusability of components.

websocket -> java -> quarkus

so later anyone can add websocket -> java -> spring and others, but just meshing existing components and adding only small differences to the template

and later if you want to do amqp then it will be amqp -> java -> quarkus

it might sound like overhead, but only if reusability is no taken into account from the very beginning

[ssala034]

Okay thanks for clarification. I think developing that is worth it for the long run.

As for the Models in modelina, I should take a look at that.

[ssala034]

Initial solution has been merged #1623