Folks, Can I request some insight into the continued dependency on swagger-codegen in NiFi-2.x. I note that the update to swagger-codegen from 2.x to 3.x was implemented by David Handermann last year in this ticket[1] for reference, it seems clear the aim was for minimal changes and backwards compatibility which I certainly agree with.
I ask because swagger-codegen is largely superseded by openapi-codegen since the fork in that community around 2018, and most of the modern tools I see now use openapi instead. I note that there is a ticket[2] from Matt Gilman and others somewhat asking for this. For clarity, the output of both swagger and openapi is marked as OAS 3.0.1 compliant, but they are not actually intercompatible - you cannot use the output of swagger-codegen from NiFi with openapi-codegen or similar popular tools without heavy modifications. Insomuch as OpenAPI is the 'successor' to Swagger, this occurred around the OAS3.0.1 release that NiFi-2.x has moved to, and thus the murky spec compliance waters. I am interested primarily because the opportunity to move to modern tooling to maintain critical NiPyAPI components like Authentication is far more appealing than upgrading the existing hand-coded templates. Would the community be interested in adopting a more modern API-spec output that is directly compatible with these more current tools, possibly in parallel with the existing swagger-codegen output to sustain backwards compatibility? I am thinking along the lines of an additional build artefact generated entirely with OpenAPI dependencies on the assumption that there may be good reasons for leaving the existing Swagger artefact untouched. I essentially want to solicit feedback before diving into it myself. [1] https://issues.apache.org/jira/browse/NIFI-11276 [2] https://issues.apache.org/jira/browse/NIFI-2978
