Avoid duplicated generations when using multiple tags
Resolves: #13615
Basically all of the generators, but Micronaut are generating duplicated routes in the presence of multiple tags. I believe this is a bug and only the Micronaut implementation offered a workaround for this issue. Here I propose to fix the actual bug while still preserving the original behavior of the Micronaut parameter.
PR checklist
- [X] Read the contribution guidelines.
- [X] 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.
- [x] Run the following to build the project and update samples:
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./mvnw clean package ./bin/generate-samples.sh ./bin/utils/export_docs_generators.sh./bin/generate-samples.sh bin/configs/java*. For Windows users, please run the script in Git BASH. - [X] File the PR against the correct branch:
master(6.1.0) (minor release - breaking changes with fallbacks),7.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.
cc. @andriy-dmytruk as it's involved in the Micronaut implementation
cc. @wing328
This change brings unified handling of tags across all templates (which is desired), removes duplication of source code that is generated. This is important for languages like go where all structures landing in the same namespace causing compilation issues.
Picking first tag is the most desired option in most of the cases and API creators can adjust their tags if they want to.
Thanks a lot, @wtrocki for sharing the additional context 👍 appreciated!
Hey @wing328, can you please take a look at this PR? We are kinda blocked by it. 😢
While waiting for the fix (which is needed) I would recommend normalizing the schema. Example of existing normalizations: Normalization of the OpenAPI spec
Normalization rule is now included in last release. See https://github.com/OpenAPITools/openapi-generator/pull/14465
Thanks @wtrocki for the heads up!
I'm speechless, three different ppl pinging the maintainer, an issue, a PR and everything have been ignored for months.
The maintainers of this repo are rolling their own business, this is NOT how OSS works.
Now, it will be interesting to understand the affiliation of this project and make it clear in the Readme to settle expectations with possible contributors.
Oh, didn't notice the other PR...