-
-
Notifications
You must be signed in to change notification settings - Fork 6.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[JAXRS-spec] Use Microprofile Openapi annotations instead of swagger #795
Comments
Yes this would be great... Related discussion is #27 and the more I participate in the MicroProfile Project, the more I am convinced that it is the way to go. My approach was more: we could propose a new generator for MicroProfile (also based on With version containing breaking changes ( Is your issue just a wish or are you ready to invest time on it (development, testing, ...)? Let me know, maybe we can work together on it. |
Currently my approach is to remove the swagger annotations by using a boolean switch in the mustache templates. Because the microprofile openapi spec allows to merge YAML API definition with annotations, it is enough to have just the YAML definition together with the generated code. |
I did not understood your last point:
|
The Microprofile OpenAPI specification allows to have just the API definition as single YAML file without any annotations in code (see here):
|
And this section describes merging the YAML with annotations. |
+1 to supporting MP OpenAPI! that's an interesting approach @michbeck100 - if someone already has an OpenAPI v3 YAML file before the code they're likely (but not exclusively) using a design-first approach, in which case the code should not deviate from the static file..which creates the question on whether or not do we need OAS3 annotations at all? Looking from the other side of the coin, I think that it's probably good to generate the MP OpenAPI annotations for some reasons:
So perhaps this issue can be staged: Stage 1: generate a pure JAX-RS app from an OAS3 doc (also adding Thoughts? |
As I wrote in #809, I think it would be nice to have 2 generators:
=> I am open for better name. The generators should produce a meaningful project (README, pom.xml, ...) so that it is easy for the user to start. The generator could also provide the possibility to select the implementation. The "library" option can be (mis)used to allow to pre-configure one app server:
As far as I understood switching implementation is only a matter of different libraries in the pom and chapter in the readme. => also open for feedback. For "Stage 1" we are not that far: |
Stage 1 is already finished with #813. It just removes all swagger parts like annotations, imports and dependencies. @arthurdm IMHO when using the contract-first approach, there is actually no need for any extra annotations in the first place. Every annotation generated from the static file would be "duplicate code", because of the ability to merge the static file with annotations. For the code-first approach it makes sense to create a new generator. This would translate the static file into annotations and ignore the static file completely. This would then be the |
I agree. My reasons are more "marketing" oriented:
|
Hi, I like a lot the contract first approach and I think each change should go first to the contract and then to code, so I like what @michbeck100 is proposing and I follow his changes in the code-generator (which are working using openliberty), but I also share the thoughts of @arthurdm about the possibility of code-first. Out there in the community you always find both flavors and so to have support for both would be great and helps the microprofile community to have full support, I vote for stage 1 and stage 2 and look forward to test it. |
Hi @igbch, @michbeck100, @arthurdm, Any pointer on how what we described as "(Stage 1)" in this issue works? (doc: static OpenAPO files). I have tried to run a simple project with:
I did not managed to get it running. A simple project would help to create the corresponding generator. I think that |
I just open a sample1-helloworld on github for demonstration how to use openAPI v3 with OpenLiberty v18.0.0.3. It does not use any swagger package. Does it help? |
As people have mentioned already, there are the contract-first and code-first styles and I agree that it would be valuable if the generator supported both. There's a third style in which the same developer sometimes updates the contract first and at other times updates the code first. She might start out by defining the contract, then use a tool like this one, then as she adds endpoints to the code (adding the annotations along with it) the contract becomes obsolete until she updates it or generates/fetches it as with the support for OpenAPI in MicroProfile. One could argue this is a messy approach, but I'd think it is out there. For that reason might it be useful to include the MicroProfile OpenAPI annotations in the generated code -- at least provide an option to do that? Even though, as mentioned earlier, that would replicate what the OpenAPI document conveys, doing so would not affect the functionality. |
I have started to work on this again... (targeting Quarkus in my case, but any other app server like OpenLiberty, Thorntail, …) should works too. I spoke about this earlier this week: --
Especially in the second case, using the generation-gap pattern is interesting: You consider that the JAX-RS endpoints must be generated: they only delegate to an other class that need to implement an interface that is also generated. Such a pattern is implemented in the |
For the "Static file" approach, I have proposed PR #3901 |
The OpenAPI annotations are definitively the way to go! It now seems that the SmallRye OpenAPI project provides a way to use those annotations on top of Spring instead of JaxRS. |
Is there a solution for this? |
…kus library in JaxRsSpec
…kus library in JaxRsSpec
…kus library in JaxRsSpec
…kus library in JaxRsSpec
…kus library in JaxRsSpec
…kus library in JaxRsSpec
…kus library in JaxRsSpec
…kus library in JaxRsSpec
Created the PR #15407 to add Microprofile OpenAPI annotations. |
…kus library in JaxRsSpec
…kus library in JaxRsSpec
…kus library in JaxRsSpec
…kus library in JaxRsSpec
…kus library in JaxRsSpec
…kus library in JaxRsSpec
…kus library in JaxRsSpec
…kus library in JaxRsSpec
…kus library in JaxRsSpec
…kus library in JaxRsSpec
…kus library in JaxRsSpec
The PR #15407 enables Microprofile OpenAPI annotations when option "useMicroProfileOpenAPIAnnotations" is set to true.
@wing328 Is it possible to speed up the merge of this PR? |
…kus library in JaxRsSpec
…kus library in JaxRsSpec
…kus library in JaxRsSpec
…kus library in JaxRsSpec
…kus library in JaxRsSpec
…kus library in JaxRsSpec
…kus library in JaxRsSpec
… Add OpenID support (core) (#15407) * Issue #795: Add microprofile OpenAPI annotations for quarkus library in JaxRsSpec * Issue #795: Add microprofile OpenAPI annotations for quarkus library in JaxRsSpec * Issue #795: Add microprofile OpenAPI annotations for quarkus library in JaxRsSpec * Issue #795: Add microprofile OpenAPI annotations for quarkus library in JaxRsSpec * Issue #795: Add microprofile OpenAPI annotations for quarkus library in JaxRsSpec * Issue #795: Add microprofile OpenAPI annotations for quarkus library in JaxRsSpec * Issue #795: Add microprofile OpenAPI annotations for quarkus library in JaxRsSpec * Issue #795: Add microprofile OpenAPI annotations for quarkus library in JaxRsSpec * Issue #795: Add microprofile OpenAPI annotations for quarkus library in JaxRsSpec * Issue #795: Add microprofile OpenAPI annotations for quarkus library in JaxRsSpec * Issue #795: Add microprofile OpenAPI annotations for quarkus library in JaxRsSpec * Issue #795: Add microprofile OpenAPI annotations for quarkus library in JaxRsSpec * Issue #795: Add microprofile OpenAPI annotations for quarkus library in JaxRsSpec * Issue #795: Add microprofile OpenAPI annotations for quarkus library in JaxRsSpec * Issue #795: Add microprofile OpenAPI annotations for quarkus library in JaxRsSpec * Issue #795: Add microprofile OpenAPI annotations for quarkus library in JaxRsSpec * Issue #795: Add microprofile OpenAPI annotations for quarkus library in JaxRsSpec * Issue #795: Add microprofile OpenAPI annotations for quarkus library in JaxRsSpec * Issue #795: Add microprofile OpenAPI annotations for quarkus library in JaxRsSpec * Issue #795: Add microprofile OpenAPI annotations for quarkus library in JaxRsSpec * Issue #795: Add microprofile OpenAPI annotations for quarkus library in JaxRsSpec * Issue #795: Add microprofile OpenAPI annotations for quarkus library in JaxRsSpec * Issue #795: Add microprofile OpenAPI annotations for quarkus library in JaxRsSpec * Issue #795: Add microprofile OpenAPI annotations for quarkus library in JaxRsSpec * Issue #795: Add microprofile OpenAPI annotations for quarkus library in JaxRsSpec * Issue #795: Add microprofile OpenAPI annotations for quarkus library in JaxRsSpec --------- Co-authored-by: Nuno Borges <[email protected]>
The PR #15407 was merged in master branch, it is expected to be released in version 6.6.0. |
Description
Moving forward to OAS 3.0 the openapi-generator should have the option to switch from Swagger annotations in the generated code to annotations from the Microprofile OpenAPI Specification.
The text was updated successfully, but these errors were encountered: