[REQ] [java-micronaut-server] Option to generate library style output instead of a project skeleton (like java-spring interfaceOnly=true)

Is your feature request related to a problem? Please describe.

I am using the java/kotlin spring generators exclusively with the interfaceOnly flag set to true.

This option in those generators were the key to achieve contract first development with openapi-generator when multiple teams depending on the code that is generated from the spec.

I am interested what the maintainers and the community thins about this approach. How well this would fit into the current generator. If this is something that worth adding then I am also open to contribute this.

@andriy-dmytruk

Describe the solution you'd like

Replicate the spring generators interfaceOnly behaviour for the micronaut generator.

Describe alternatives you've considered

The generateControllerAsAbstract does something really similar, but the output still an project skeleton. It includes the Application class, application.yaml, the controller package with default impls, tests, and shadow jar plugin for builds.

For the library approach, these are all unnecessary and also block building just a regular artifact with only pojos and interfaces.

Additional context

I will provide some context how I would implement contract first interface design through an example:

The workflow goes like this:

• each team has their own repository, e.g. frontend with some js framework, an analytical app in python, and the backend with the micronaut app
• the OpenAPI specification is living in a separate repository
• in the repository with the OpenAPI specification theres a tooling that generates artifacts for each team relying on the this - npm package for the frontends, python "sdk" in a PyPl package, and a JAR for the server, maybe Feign clients if there are multiple backend services

Client generators are inherently (at least the ones I used so far) generates code in library layout that can be packaged and distributed, so nothing surprising there.

Spring interfaceOnly only generates annotated models and annotated interfaces for the APIs. No application class, no application yaml. no dev tools dependency or spring boot repackage plugin. This is really nice because this can be built and distributed as a regular jar, as library.

After this, we just pull this JAR as a dependency into a regular spring boot app generated by spring initializer for example, and implement the interfaces.

This way the contract can evolve independently from the backend. Clients can start development even without the backend by using the generated API code and using stubs/mocks for testting.

As an additional feature, an improvement over how the spring interfaceOnly feature works, these builds would also attach a sources jar to the published artifact. This helps developers when they are inspecting the generated files that are imported as a dependencies - it always much nicer to look at sources instead of decompiled class files. It would also retain javadoc (which is not really relevant as the micronaut generator not outputting them)

Start by comparing the java-micronaut-server generator with the Java/Kotlin Spring generators' interfaceOnly behavior, including the existing generateControllerAsAbstract option. Define the library output boundary described in the issue—models and API interfaces without the application skeleton—and verify that the generated artifact can be built and packaged independently.