OpenAPITools / openapi-generator

OpenAPI Generator allows generation of API client libraries (SDK generation), server stubs, documentation and configuration automatically given an OpenAPI Spec (v2, v3)
https://openapi-generator.tech
Apache License 2.0
21.29k stars 6.44k forks source link

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

Open zaenk opened 1 year ago

zaenk commented 1 year ago

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:

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)

andriy-dmytruk commented 1 year ago

There is work to improve the micronaut generation and support what you are describing for micronaut 4.0.x. See: micronaut-projects/micronaut-openapi/issues/1037.