Why not extend and improve openapi-generator?

[InfoSec812]

The work here is interesting and really nice for some Quarkus use cases, but I would love to see these same improvements get moved back upstream into https://github.com/OpenAPITools/openapi-generator so that other JAX-RS/Rest implementations could benefit from it. What would it take to be able to push these changes back upstream instead of diluting the effort and the community?

[hbelmiro]

@ricardozanini I think you're the best person to answer this.

[ricardozanini]

@InfoSec812, thanks for your question! Sorry for the delay; I was on vacation.

Most use cases in this repo are specifically for Quarkus, even the template engine is different. We don't have any specific changes to the core OpenAPI Generator to revert to them. That's why we haven't moved anything.

Is there any specific feature you'd like to see that's a one-to-one replacement there?

[InfoSec812]

My real concern is that this will cause divergence over time and duplicate efforts which could be consolidated. For example, a lot of the REST/JAX-RS implementation would be beneficial to multiple generators and now with this separate effort those improvements will not get propagated to the rest of the OpenAPI community. Also, it's a division of the available contributors who focus on OpenAPI and code-gen. We pull a few people away from contributing to OpenAPI Generator and we lose all of those who remain with the original project and thus are not as capable as we could be if we continue combining efforts.

[ricardozanini]

I'm sorry, @InfoSec812, but I don't see duplicate efforts here. We are essentially using the upstream lib to parse the OpenAPI and the API data model. The templates and use cases are tailored specifically for Quarkus. We could change our templates to mustache and push to the upstream, but again, useless work IMO. People that use Quarkus can just use this extension.

Every time I see a bug or a feat that can be on upstream, I push there. But again, I don't see pushing this entire project upstream. Additionally, we are considering changing the parser and API model so we won't use the OpenAPI generator in the mid-term.

[InfoSec812]

I can see that I will have no success explaining, but I will say that this is disappointing. The upstream OpenAPI Generator is so much more capable and I would love to see the Quarkus support there get even better rather than splitting the focus and developer effort.

[ricardozanini]

@InfoSec812 the problem I see migrating this code base is that it won't provide the extension architecture we have in this model. Again, we push to the upstream every time we see a bug or improvements to the generator.

I'm sorry that you're disappointed, but what would you suggest? To move this entire infrastructure there? How we would accomplish this? I'm not against any changes that could strive for a wider gain for the community.