[Microprofile] Add option to use tags a client keys and server generator

[kiwi-oss]

This adds two features for Microprofile.

One is the configKeyFromClassName option that allows naming the configuration key of the @RegisterRestClient annotation after the annotated API interface.

The effect can be seen in the interfaces under samples/client/petstore/java/microprofile-rest-client/src/main/java/org/openapitools/client/api. Compare to those under e.g. samples/client/petstore/java/microprofile-rest-client-3.0-jackson/src/main/java/org/openapitools/client/api where a fixed key is used.

The other addition is a server generator which has the feature of properly handling cases where multiple HTTP 2xx responses are defined, see GET /pet/findByTags in modules/openapi-generator/src/test/resources/3_0/petstore-multiple-2xx-responses.yaml.

The various 2xx responses can return different things, e.g. 200 the whole resource, 204 nothing, 206 a partial resource and so on. Therefore, the return type of the related server interface method has to return a generic response type. This can be seen for findPetsByTags in samples/server/petstore/microprofile/src/main/java/org/openapitools/server/api/PetApi.java.

@bbdouglas @sreeshas @jfiala @lukoyanov @cbornet @jeff9finger @karismann @Zomzog @lwlee2608 @martin-mfg

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project and update samples:

  ./mvnw clean package 
  ./bin/generate-samples.sh ./bin/configs/*.yaml
  ./bin/utils/export_docs_generators.sh
  

  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  For Windows users, please run the script in Git BASH.
• File the PR against the correct branch: master (upcoming 7.1.0 minor release - breaking changes with fallbacks), 8.0.x (breaking changes without fallbacks)
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

[wing328]

https://github.com/OpenAPITools/openapi-generator/actions/runs/6312654633/job/17293794844?pr=16673

looks like there're some unresolved merge conflicts

do you minding merging the latest master into your branch and regenerating the samples?

[kiwi-oss]

Done. Sorry for the delay, I was on holidays

[kiwi-oss]

@wing328 There is still some failure, but it seems to me that it's not related to my changes because it's in some JavaScript code.
Can you advise how to proceed with this?

[wing328]

@kiwi-oss thanks for the PR. please PM me via Slack when you've to further discuss this.

https://join.slack.com/t/openapi-generator/shared_invite/zt-12jxxd7p2-XUeQM~4pzsU9x~eGLQqX2g

[wing328]

can we name the generator as "java-microprofile" instead following the convention of other java server generators?

[oscarobr]

done

[wing328]

please add the new folder to .github/workflows/samples-java-server-jdk8.yaml so that CI will test it moving forward

[oscarobr]

done

[wing328]

personally I would suggest NOT to extend a java server with JavaClientCodegen as most options available in JavaClientCodegen won't make sense in the server generator if I understand it correctly.

[oscarobr]

The java generator, using the microprofile library, generates an interface that could be used for either client or server.

This is what is being extended. I understand that it seems odd to have a server code generator inherit from a client generator. But we would have to re write the functionality of the java generator.

Do you have a suggestion of how to proceed with this?
Or perhaps it could be listed as a MicroprofileClientCodegen because it could be used for either client of server

[wing328]

right seems odd but to me but it's not a showstopper.

if this way is a good starting point to add the server generator for microprofile, i'm totally ok with that.

[wing328]

can you please review the test failure when you've time? https://github.com/OpenAPITools/openapi-generator/actions/runs/8880595750/job/24389070322?pr=16673

[oscarobr]

can you please review the test failure when you've time? https://github.com/OpenAPITools/openapi-generator/actions/runs/8880595750/job/24389070322?pr=16673

This is caused by a mixing of Junit 4 and Junit 5, and unsatisfied dependencies. It seems this was introduced in 7.5.0 and that there have been issues raised for it /issues/18465

[oscarobr]

can you please review the test failure when you've time? https://github.com/OpenAPITools/openapi-generator/actions/runs/8880595750/job/24389070322?pr=16673

This is caused by a mixing of Junit 4 and Junit 5, and unsatisfied dependencies. It seems this was introduced in 7.5.0 and that there have been issues raised for it /issues/18465

The java microprofile library does not build generate correctly, as the microprofile/pom.mustache does not contain the junit 5 dependencies. I noticed that when regenerating the samples it does not modify these existing samples, so the issue has not been uncovered. I have switched the samples generation to junit 4 to resolve my failing build, but there should be a larger fix for the microprofile library

[wing328]

can you please review the test failure in https://github.com/OpenAPITools/openapi-generator/actions/runs/8892195364/job/24617679907?pr=16673 when you've time?

[oscarobr]

can you please review the test failure in https://github.com/OpenAPITools/openapi-generator/actions/runs/8892195364/job/24617679907?pr=16673 when you've time?

done

[wing328]

thanks for the PR. all tests passed. if no one has further feedback, I'll merge it tomorrow.

cc @bbdouglas (2017/07) @sreeshas (2017/08) @jfiala (2017/08) @lukoyanov (2017/09) @cbornet (2017/09) @jeff9finger (2018/01) @karismann (2019/03) @Zomzog (2019/04) @lwlee2608 (2019/10) @martin-mfg (2023/08)