I think there are two separate parts to consider... The work in NIFI-11276 was for nifi-toolkit-api which takes the swagger.json from nifi-web-api and generates a Java client from it. So this isn't really related to generating the spec itself, it is consuming the spec and generating a client, similar to NiPyApi generating the Python client.
The spec itself is generated during the build of nifi-web-api from the swagger-codegen-maven-plugin processing all of the Java classes for the REST resources and inspecting the Swagger annotations, so it is a Java first approach, meaning there is no swagger.json in source control that as is maintained. I think the issue with moving to open-api is mostly just a matter of effort, someone has to update all the dependencies/plugins and go through every single Java REST resource and method and change the annotations from Swagger to the corresponding Open API annotations. Others may know more about this and can correct me if I am wrong. On Tue, Oct 22, 2024 at 9:43 AM Daniel Chaffelson <chaffel...@gmail.com> wrote: > > 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
