Generator should also provide org.openapitools:openapi-generator Integration for Server - Stubs

[michaelsonnleitner]

Tell us the extension to which you'd like to add the feature.

Server

What kind of feature would you like to add?

MP REST Client generation relies on relies org.openapitools:openapi-generator (link) and it works fine and is extremely configurable.

Server Stub generation currently relies on Apicurio which is nice and good but not that configurable as as OpenAPITools-openapi-generator.

In my opinion server stub generation should also rely on OpenAPITools-openapi-generator libary because issues like

• Support additional-model-type-annotations for Server Generator #1273
• Cannot generate MultipartForm server-side API #1154
• Polymorphism with discriminators is not working #1133
• Server Code Generation does not support multiple yaml files #983
• Resources grouping ignoring tags with common path name and different resources #675

would be fixed.

org.openapitools:openapi-generator is build on the use of yamls which is the most common way to write business openapi Specifications (e.g. newlines in json's are not really possible, petshopstore - sample is never a good sample for openapi spec because the main parts - good documentation is missing).

In the current state of server stub generation the yaml has to be converted to json - and converting between formats is never a good idea because info can be lost or mismapped. I also think that there is a bigger community around org.openapitools:openapi-generator (see github stars, ...)

Proposal(s):

In my opinion server & client generation could / should be nearly the same regarding the codebase - if you compare for example the PetsApi (MP-REST Client) vs. PetsResource (JAXRS Server) they do not differ that much. They differ only in some points (eg. RegisterRestClient, CDI-Scopes).

Client generation with org.openapitools:openapi-generator is currently really powerful (regarding configuration, extensibility).

Try to extend this powerful mechanism also to be used in server stub generation.

Alternative(s):

No response

Additional info:

No response

Community Notes

No response

[mcruzdev]

Hi @michaelsonnleitner, thanks for this proposal.

Server Stub generation currently relies on Apicurio which is nice and good but not that configurable as as OpenAPITools-openapi-generator.

org.openapitools:openapi-generator is build on the use of yamls which is the most common way to write business openapi Specifications (e.g. newlines in json's are not really possible, petshopstore - sample is never a good sample for openapi spec because the main parts - good documentation is missing).

In the current state of server stub generation the yaml has to be converted to json - and converting between formats is never a good idea because info can be lost or mismapped. I also think that there is a bigger community around org.openapitools:openapi-generator (see github stars, ...)

Client generation with org.openapitools:openapi-generator is currently really powerful (regarding configuration, extensibility).

You really shared good points about the benefits of to use OpenAPITools-openapi-generator.

[mcruzdev]

In my opinion server & client generation could / should be nearly the same regarding the codebase - if you compare for example the PetsApi (MP-REST Client) vs. PetsResource (JAXRS Server) they do not differ that much. They differ only in some points (eg. RegisterRestClient, CDI-Scopes).

Actually the client side uses Qute template engine for generating the client code, I know that the code base is very similiar, but I have some cautions about the template maintanability, duplicity, etc. Really we need to investigate it better, to provide a best solution for this, because we still need to provide Apicurio.

[michaelsonnleitner]

hi @mcruzdev . i understand your point. putting client and server to the exact codebase (especially in templates) is not the best way. template overriding in openapi codgen is a very good option - in my experience is quite good powerful. (imaging you build a base set and in client and server you override those you need - splitting templates is essential, small ones are better...)

models java classes should be the same in both.

a lot of configuration possibilities can be used in server mode also (really great job at client part already)

hope your internal investigation also figurs out the this ideas.

greetings michael

[mcruzdev]

@michaelsonnleitner I think we can do the following, in order:

1. Support org.openapitools:openapi-generator for Server extension using Qute, probably we will copy some templates from Client side.
2. Create a generic/core module that supports multiple implementations (this one was requested by this issue Support for plain Java clients  #82)

What do you think @ricardozanini @hbelmiro?

[michaelsonnleitner]

@mcruzdev : great to hear that. if you need support in some details - i have some years of knowledge in openapi-codegen. let me
know.