Created by: shybovycha
Introduction
There is one quite nifty but undocumented option, apis
, which could be set in system properties. It defines which API groups should be generated. Given the undocumented internal behavior of grouping all operations by tags, this gives an easy way to migrate existing projects to Open-API with minimal changes by automatically generating API definitions and then generating API interfaces with operations automatically grouped according to the existing endpoints.
Hence I am creating a few PRs (#4937, #4938, #4939) addressing this hidden gem of openapi-generator
.
This change
Using tag as the primary key to group paths and operations.
This comes extremely handy when used together with apis
system property (or additionalProperties
one, as in #4937 ) so the operations could be grouped into resources.
I tested it on our existing project together with swagger-maven-plugin
(specifically this hack) to minimize the change when migrating the whole project to Open-API (mostly automatically).
This definitely is a breaking change (as the resources generated will have different names), so targeting 5.0.x
.
PR checklist
-
Read the contribution guidelines. -
If contributing template-only or documentation-only changes which will change sample output, build the project before. -
Run the shell script(s) under ./bin/
(or Windows batch scripts under.\bin\windows
) to update Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit, and these must match the expectations made by your contribution. You only need to run./bin/{LANG}-petstore.sh
,./bin/openapi3/{LANG}-petstore.sh
if updating the code or mustache templates for a language ({LANG}
) (e.g. php, ruby, python, etc). -
File the PR against the correct branch: master
,4.3.x
,5.0.x
. Default:master
. -
Copy the technical committee to review the pull request if your PR is targeting a particular programming language.