search

OpenAPITools / openapi-generator

OpenAPI Generator allows generation of API client libraries (SDK generation), server stubs, documentation and configuration automatically given an OpenAPI Spec (v2, v3)
https://openapi-generator.tech
Apache License 2.0
21.81k stars 6.58k forks source link

[Question] Do people successfully use this? #7490

Closed black-snow closed 4 years ago

black-snow commented 4 years ago

This may sound like a rant but that's not what's intended. I'd actually like to know if people successfully use this tool to generate code that runs in production because my experiences are pretty bad so far.

The first issue for me was: okay, there's swagger codegen that has 2.5k issues and then there's this fork which also has 1.7k issues. That's a huge warning sign already. But look, there's a ton of generators and things it does so that might be okay. But which one do I use now? I tried both and the results were the same.

I haven't tried the other generators. Maybe I'm the only one trying to generate client code for java and resttemplate. I have a bunch of issues. Unclear docs, Syntax errors in the generated gradle, missing dependencies in the generated build.gradle, array with anyOf is not supported - I have to manually add a parent type and let the subtypes extend this, I have to explicitly set openApiNullable to true in the gradle plugin in order to have the dependency added although it defaults to true (according to the docs). And after all of this I still cannot use it because some nullable field fails in my spring app

Cannot construct instance of `org.openapitools.jackson.nullable.JsonNullable`

despite the config being set up.

Again, please don't get me wrong. I'm sure that lots of effort has gone into both projects. Maybe I'm just doing something wrong? Although OAS 3.0.3 is from February the original 3.0.0 is quite dated. I can't imagine that the generator just does not work - I mean, it's version 5 already.

For my current project my idea was to go spec first and have the client generated with a single button click. OAS isn't new anymore so the tooling should be good by now. But now I've invested some days without success and I guess I'll have to fall back to manually annotating my POJOs and stitching stuff together with Restteample or Retrofit myself.

toby-murray-snow-software commented 4 years ago

As an anecdote, I can say that the Cloud Management team at Snow Software uses OpenAPI specs in production and has been for a couple years. We have one spec that's ~21k lines, another that's ~2k lines, and we are moving forward with more.

That said, in total we use ~4 or 5 versions between the Swagger generator and the OpenAPITools generator because almost all of them have at least one bug that impacts us. We generate Java clients, Java server stubs, and TypeScript clients.

You should expect to be overriding some of the templates to suit your own purposes. Even if it's just to keep dependencies more up to date than this project does, this is not a "run this jar and forget about it" project in my experience.

My personal opinions

black-snow commented 4 years ago

That's a very valuable response, thank you very much! I hope there will be more users reporting in.

IlyaLoshchinin commented 4 years ago

@black-snow You are definitely not alone. I have exactly the same problems as you and I don't understand how people use it to generate the api clients (java, spring boot, openapi-generator-maven-plugin:4.3.1). It just doesn't work! I've been trying to use the 5.0.0-beta2 version of plugin with switched 'openApiNullable' property off, but the generator doesn't generate the interface for schema oneOf. https://github.com/OpenAPITools/openapi-generator/issues/6816 Then I decided to leave jackson-databind-nullable feature which is required for 4.3.1 version. (no property to disable it). I've started to use the generated clients and I began to receive the same issue. https://github.com/OpenAPITools/jackson-databind-nullable/issues/18 @black-snow Did you circumvent these issues in some way? Thank you.

agilob commented 4 years ago

that has 2.5k issues and then there's this fork which also has 1.7k issues. That's a huge warning sign already

No it isn't. IMO having issues open is much better than letting bots close it after 3 month. Issue is an issue, and it doesn't just expire because some time past since it was opened. Probably a lot of these issues are duplicates, incorrectly used tool or question that just do not get answer, or were simply fixed without closing the issue. Recently had a discussion with one tech lead who decided to use react-native over flutter, because react native has less issues open on GH. RN automatically closes issues after some time, Flutter doesn't. It's a psychological bias, it's up to you to fight it.

Maybe I'm the only one trying to generate client code for java and resttemplate. I have a bunch of issues. Unclear docs, Syntax errors in the generated gradle, missing dependencies i

These are real issues. Unfortunately openapi is a massive project with huge complexity. Not all config options can be tested. I remember seeing some progress being made on this front = using most complex schema to test all generators. It's a process. Not all generators are mature enough to support it, many will produce code that doesn't compile, so it's a step-by-step process. If you encounter an issue, add comment to it, add your example. The better documentation of a bug, the more likely it is to be resolved soon.

I've seen many complex OSS that do a lot of things and to put it softly "aren't good at it". When OSS gets big community, community concentrates on developing as many features as possible, sacrificing quality. This tool is from developers for developers. Devs can't test properly, do not do QA, do not like maintaining software once its identified with bugs.

I advice maintainers (in general) to put a hard stop on accepting new features until xx% of bugs are fixed. Apple did it once, they once made a OSX release that had no new features, but had a few thousands of bugs fixed. Pure bug-fix release would be nice, especially it's hacktoberfest and a lot more contributors with little experience will come.

Yes, I've used openapi on a production system, but we used it in a completely different way you described.

Business/process analysts had access to our openapi schema. Produced code was packaged as jar, pretty much without any modification, pure generated code. BA/PA/devs and testers were able to modify the file, run jenkins on repo and release it. The generated code was our core of the product, controlling main behaviour with feature flags. Eg. BA could quickly go to the schema, change default value of a boolean, deploy code and see new behaviour without asking devs to change feature flag on server instance.

black-snow commented 4 years ago

Thanks for your reply agilob.

No one asked whether it's good to auto-close open issues or not and 1k+ open issues IS a huge warning sign but let's not start this discussion here, that's not what this issue is about. It's also not about why things are like they are - it's pretty obiously a huge project. The question was if people do actually use this productively (and if yes, how). So thanks for your last paragraph. Was your schema simple enough or do you use another language / generator? Because right off the bat the generated code doesn't even compile for me.

agilob commented 4 years ago

My whole comment was building up to the last paragraph. We used it for something "simple". Our schema was generating over 50 models, a few models were added every month.

I find autoclosing issues and complexity of this project important to answer your question.

Was your schema simple enough or do you use another language / generator? Because right off the bat the generated code doesn't even compile for me.

Whole project was in maven+Java.

Because right off the bat the generated code doesn't even compile for me.

Like said before, it's a complex project from developers for developers. The generator you used didn't work, but 60 others most likely work. I understand your disappointment, but what other generators have you tried?

The question was if people do actually use this productively (and if yes, how)

Yes, people use it on production. OpenAPI is also a contract. Small companies use it, seen it in a blockchain projects, I'm sure redhat uses it internally.

jimschubert commented 4 years ago

@black-snow those are some great questions, and excellent feedback. I know I'm a maintainer, so my feedback is heavily biased and one might consider "advanced usage". I'll explain my use cases and dive deeper into your concerns.

My production experiences

When I was at Expedia, I used swagger-codegen generated code and later openapi-generator generated code (after we forked the project) to generate a Scala Finatra client in a Spark Structured Streaming application. This was a custom generator because our project doesn't include a Finatra output, and we had internal observability tools which I had to integrate into the code.

I also used the JavaScript node.js client generator to generate contract tests which we ran in the backend API pipelines for my team on every build.

Just before I left Expedia, I'd written a custom generator to generate some pact tests with a goal to replace the node.js contract tests. There was nothing wrong with the tests, my team just wasn't comfortable with JavaScript-based tests so we were moving to JSON-based tests (I know… don't ask me).

When I started using the generator, my team had 7 APIs which totaled around 40 endpoints and maybe 200 models. When I left there were only 3 APIs but 2-3x the endpoints and models.

The Scala Finatra client code was running in production, and while the other code was test code it was integral in getting other code to production. We didn't use generators to generate our server code because: 1) our codebase had a more complex architecture than the standard controller/service type of output you'll find in our generators 2) we were not following spec-first development.

My current employer uses OpenAPI documentation for spec-first development across all APIs - of which there are 100s or maybe 1000s. I plan to work with an internal team to integrate OpenAPI Generator into some of our internal tooling to simplify client/server/doc generation for the entire company.

Are others using it?

Absolutely.

Also, as @agilob points out, it's best to have a ton of issues because it shows there are a ton of users. It also means we're not just randomly closing issues because we don't hear back from people for a couple weeks. The issues are the project's backlog. Just think what would happen if you went to work tomorrow and started deleting hundreds of Jira tickets because your Project Manager hadn't commented on them in two weeks. I could never understand how projects mark issues as "stale"; something is either an issue or it's not. Just like we can't wish away Coronavirus, we can't wish away the technical debt in open source.

There's another reason why we have so many issues, though. Many of them are already fixed as a matter of course and we sometimes don't close associated issues until a release has been completed. Many of our issues are duplicates where people don't realize that one or more issues are describing the same thing. Some of the issues don't follow our issue reporting guidelines (no sample inputs, no expectations, no generator version). More still are a result of the user trying to generate against an invalid or incomplete spec document, which is not something we support. Interacting with all of those issues takes time. In fact, at one point our core team was collectively spending a few hours a week just labeling issues and pull requests. This drove me to write a labeler github app to reduce our maintenance overhead. That worked, but since it's a hosted GitHub app, it came with its own maintenance overhead... so I wrote a labeler GitHub action instead.

Yet another reason why there are so many issues is time. Everyone who contributes to this project does so in their free time. We have to manage our time between new code contributions, reviewing pull requests, and community engagement. I'd read somewhere that more than half of open source contributors spend 5 hours or less a week on open source. I usually average closer to 10 hours a week. I think a project this size with the amount of contributions made and merged on a weekly basis would be considered "very active" in open source.

Your linked concerns

Your linked concerns are very valid. I have been working for over a year on Project 5: Simplify Contributions and Improve Usability specifically to ease the pain that newcomers feel when using OpenAPI Generator. When I first began contributing to Swagger Codegen 4-5 years ago, I really enjoyed it because I considered it a challenge to dig in and understand how everything worked. But, that's not a good user experience if all your users have to do the same. This is why the first thing I did after the fork was to create a roadmap which helped us be a little more transparent about where we intended to go with the project.

I've also spent maybe 100 hours or so organizing and creating developer-facing documentation at https://openapi-generator.tech/ which explains usages and provides examples for using templates and fully customizing generators.

It's important for folks to read these docs, and they can always use some additional love. Unfortunately, most developers don't really like writing docs (myself included). And since this is a community-driven project we really do rely on contributions from the community to help improve things for the community.

I hope you don't mind if I use you as an example related to documentation… I mean no offense it just shows the issues around open source and our reliance on community. You'd referenced our docs in #7479, which you begin with:

Couldn't find a repo for the gradle plugin so I'm posting this here.

The gradle section of the docs ends with:

For full details of all options, see the plugin README.

See below:

image

The plugin README links directly to the readme within this repo from which the gradle plugin is built.

That readme lists all available options. The configOptions you asked about are documented as:

A map of options specific to a generator. To see the full list of generator-specified parameters, please refer to generators docs

I'll admit that I don't consider myself a technical writer but I do try to make things as clear as possible when communicating concepts. Unfortunately, I have "expert bias" as a core contributor so it's often difficult to write docs as if I'm a first time user. We rely on issues and bug reports from users to improve these. When a user raises a concern like yours, it indicates to me that the README link for the plugin probably also needs to be included closer to the first example. As another example, your question about why some configs are not nested within configOptions is a concern I've raised in the past but which had no real feedback from the community as a perceived problem, so it hasn't had priority.

Your comments about "doing something wrong"

You're not doing anything wrong. I think you are approaching code generation tooling as if it'll output production-ready code which will fully suit your needs, and that this approach is frustrating you. That assumption is sometimes not the case with code generation tools which are bound to dynamic user-defined inputs.

In many cases, our clients will just work right out of the box for maybe 95% of the use cases (see our ruby, kotlin, C#, and aspnetcore generators, for example). In some instances, the code may require template customization as others have mentioned above or it may require workarounds or older versions.

In your case, specifically, I think you've experienced frustration because you're targeting Gradle builds and a generator which isn't as active as others. We have an extensive regression testing suite. While we can't possibly test all the combinations of code, we do run full compilation tests on:

So, for every build we run maybe 200 minutes of builds, tests, and integration tests which verify outputs of 100+ generated sources.

But as many of our JVM languages output Maven POM files and our project uses Maven, when we execute these samples in our CI it will execute the Maven POM in the sample. This allows for some bugs to slip by in gradle build files. Unfortunately for us, these often go unnoticed because people are probably not even relying on our build outputs in the first place (i.e. generating models/apis/docs into an existing project).

My recommendation would be if you're trying one of the generated outputs and Gradle fails, compare it against the Maven POM (or even attempt the build with Maven). If it still fails, then it's a bug. We will often fix the bug and add the generator to the list of compilation checks with the other 100 or so generated outputs.

But I want to be clear - and this echos what others have said - you should expect to do customization.

Customization

The thing that sets our tool apart from others is the customization. Our built-in templates are all mustache. We support handlebars as well. We also support custom template engines.

If templating doesn't suit your needs, and this can happen if the data bound to templates doesn't quite match your expectations, you can write a custom generator.

Until within the last couple of weeks, you were limited to generating only those templates which are known to the generator at compile time. For version 5.0.0 we'll be able to define completely new templates externally via configuration files like those we use for samples; this will be available for built-in and custom generators.

Getting Help

I hope my response was informative and answered most of your questions.

You can always reach out to our Slack channel if you get stuck. There are almost 900 users in our general chat and people often get responses from users. You're also likely to get quick responses from me on there as well. Someone could at least guide you in the right direction if you're beginning to feel frustrated by any part of the tooling.

black-snow commented 4 years ago

@jimschubert thanks a ton for such a thorough reply.

Also thanks for pointing me towards the plugin's readme. I've actually found it in the meantime. And a last thanks for putting so much efforts into this project. It's an important tool for anyone doing anything with APIs, I think, and has the potential to save kajillion of hours and repetitive work. Aight, let's get to the issues and how to resolve them. I have almost no spare time for the rest of the year but I'll happily contribute wherever and whenever I can.

Is there a special reason for the Gradle stuff not being tested? Any actual blockers? Someone mentioned having the very same issues as me but within a maven project. So that alone does not seem to help.

But I want to be clear - and this echos what others have said - you should expect to do customization.

But that's hopefully due to the size of the project and not some kind of a goal. Well, depending on what you mean by "customization". For me it's bugfixing, circumventing and failing right now. If the generated client code uses Gradle 2 and some 2015 dependencies I might be able to live with that as long as it works but it doesn't even compile. I don't even need the whole client code, the models would suffice but they weren't correct either (mostly due to lacking support for oneOf/anyOf). I mean that's fine, it's a free piece of software that many people contribute to for some greater good :) I'm just puzzled. If there are people who use this - how do these people use this? Do they write wrapper tools to fix the bugs? Are all the other generators just fine? Or am I just missing something fundamental? That was my point.

For me, right now it'd be enough to have the models generated. Writing them manually is very laborious and error prone. I had to write a custom deserializer for the anyOf part of my model because I'm just consuming an API and there's (of course) no type information encoded that jackson could use with @JsonTypeInfo. I remember that someone mentioned there's progress with jersey, I think. So I might take a look at how to copy that for WebClient and others.

@IlyaLoshchinin Thanks for reporting in. Sadly no. I'm doing things manually now since the project's schedule is tight.

jimschubert commented 4 years ago

@black-snow

Is there a special reason for the Gradle stuff not being tested? Any actual blockers?

We regularly timeout on our CI builds. We just don't have the resources to build all permutations of build systems and output options.

But that's hopefully due to the size of the project and not some kind of a goal.

Regarding customization, this should really be the goal of most of our users I would think. You won't need customization if you genuinely don't have additional observability needs and your target APIs are not very complex APIs. You likely won't need much customization for many of our client generators. You will need customization of some sort if:

black-snow commented 4 years ago

Sure, but I mean it should just compile and work in a vanilla way out of the box. (Which it does not for me atm.)

Alright, I guess I'll close this and report the issues I encounter. Thanks everyone.

agilob commented 4 years ago

Sure, but I mean it should just compile and work in a vanilla way out of the box. (Which it does not for me atm.)

I think you just got unlucky with version of generator at this time. It works most of the time ;)

wing328 commented 4 years ago

The first issue for me was: okay, there's swagger codegen that has 2.5k issues and then there's this fork which also has 1.7k issues. That's a huge warning sign already. But look, there's a ton of generators and things it does so that might be okay. But which one do I use now? I tried both and the results were the same.

Just want to add that we also use the issue tracker for feature requests, announcements, and of course issues as well. In other words, not every single issue is a bug report as it could be a feature request or just discussion.

CGavrila commented 3 years ago

I do understand there's a lot of work put into this and I don't want to insult anyone putting in the time into what is, ultimately, an opensource tool.

I have been struggling with various issues with the Java generator for days now, in two different projects. There is no way to make it work, even for a very basic project. I am trying the Maven 5.0.0 generator and it just doesn't work. There's almost nothing I can do about it except apply hack upon hack to get it to even compile. Maybe I'm just doing something wrong, but I've been trying to get a basic setup running for 2 days now and I just can't.

toby-murray-snow-software commented 3 years ago

@CGavrila - I think your statement is too broad.

There is no way to make it work, even for a very basic project.

I personally contribute to ~4 Java projects that use many different versions of the generator and 2 TypeScript projects. They all work today, albeit with compromises in some places. The generator absolutely has difficulty with sections of the OAS, and some functionality is not available.

One of the common tripping points is that there's a particular design imposed by OAS/this generator that may not be exactly what you want to express. E.g. if you're heavily doing RPC APIs or dynamic responses, it's really not a good fit and you're going to fight every step of the way.

There's almost nothing I can do about it except apply hack upon hack to get it to even compile

It'd probably be helpful for you and others to be specific - are you running into existing bugs? Are you running into erroneous behavior (i.e. you should open a bug)?

Johnlon commented 2 years ago

I needed to generate some java and python from the oas. I had been using openapi gen but it wasn't a good fit for plenty of reasons including the name mangling it does and it's inability to organise the generated files into a idiomatic directory heirarchy, and the irritation of getting mustache to work and having to figure out the complicated model presented to it. My impression of this product is that it's had too many hands in it over time , the dev practices weak and quality isn't there and I don't think it can be fixed.

So ... this afternoon I had some free time...

I was able to get a gradle build generating model files from an OAS in about 5 or 6 hours work. Really simple impl now in groovy and while I'll turn into a plugin; it's using the swagger parser to load the model and then some easy processing in groovy. I use string interpolation rather than some complicated templating engine to template the files. Now I get 100% of what I want and not the baggage and problems of openapi gen. What's more is the solution is sufficiently simple that other's will be able to extend it without the cost and complexity of OAG. It will be easy to generate the Java, Python and Go that I need.

What I'm getting at is it's actually not at all hard to roll your own and I dont' buy the value proposition of this product anymore.

black-snow commented 2 years ago

@Johnlon are you gonna os it?

Johnlon commented 2 years ago

@black-snow I'd love to but can't for reasons outside my control. But anyway like I said it's a day's work to roll your own without any compromises.

OSS'ing it would only be to demonstrate how easy it is, because the gist of my recommendation is to roll your own.

The only hard bits to figure with the swagger parser API is figuring out the right way to walk the data model (properties, $refs, allOf) to construct the fields and classes.

One decision you might want to make is whether you model single inheritance and how, eg as an allOf. If you do, then fine you can map a SINGLE allof to an inheritance relationship in the generated classes. This inheritance can be useful for statically typed languages as you can then write code thanks operating on those higher abstractions in the model of your API. However if you just want the generated Comms model classes to be flat classes then a slightly (tiny diff) different coding is needed. Regarding the benefits of inheritance and substitutability Vs just flattening , I think flattening is fine for any Lang ecosystem where ducktyping is an option; where reuse is possible any way without common supertypes. If you do go with flattening (my impl has a switch to choose) then my recommendation is a simple recursive function to collect all the field up.

Hazard... If you have self referential data structures then sometimes flattening and following $refs will fail with a stackoverflow. You can see this same thing happen inside things like the swagger resolve routines... https://github.com/swagger-api/swagger-parser#2-resolvefully as it spits error messages into the console when the search tree goes too deep.

The conclusion I've come to is this..

Use case 1: I am a service provider and as a provider I've typically only got one language to worry about, not the tons OAG provides some support for. So I dont need a tool like oag - it is not giving me 100% of what I want so roll ones own is the right approach. Sure, bigger org then maybe you have a handful (JVM, python, js, go) of service side languages but those orgs with also probably want consistency across all of them and so avoiding compromises might be even more important.

Use case 2: I am an org building internal facing client sdks for my internal clients who are using a handful of Lang's used in my org. I will probably have corporate stds (or influences) on the features and arch of these APIs. For support and evolution reasons I will want consistency across these impls so again I need to support a narrow specific Lang's and no compromises. So I will roll my own.

Use case 3: I am a client of many services and I probably only have one language in my system. I want to bake in a set of features (eg telemetry / failover) to those sdks without compromises . I only have one lang to worry about and want that customisation I will roll my owns as it's easiest way to get that features set and consistency.

Use case 4: I'm a random party on the internet wanting to generate a client side in a single language for some random service and Im not too concerned about features and consistency. I can't be bothered writing my own gen for this one off use case. So I use OAG to get bootstrapped and if my needs evolve then I can always change my mind on approach later.

Thoughts?

For me OAG is possibly ok for initial prototyping but more muture orgs will rolll their own with no compromises.

Having spent 50+ hrs figuring out the whole model passed to mustache and discovering that the java code behind each gen has significant differences on decisions on type mapping (that I disagree with) , and inexplicable differences across APIs even for variants of a single lang (eg Py) then it's clear that there isn't really any governance and consistency and generated code sometimes doesn't work (see above), and the name mangling and lack of support for idioms like subpackages for organising the generated code or big models. The generators have clearly been written by a load of different folk with different opinions on what good looks like, the codebase is a mess. It's gotten too big for it's own good and.... well ... this tool isn't really suitable for my kind of orgs.

I think fine to get you going , but once you need something even slightly different or better or less buggy then PLEASE don't do what I did.

Sunk cost fallacy..

I lived with thus thing for 18months with its shortcomings. I then recently decided I couldn't bear it anymore and tried to make things better, and spent AGES learning the detailed inner guts of this thing and discovered unhappy things , and made PRs that led to lots of debate and delay and eventuality I deleted the PRs.

Then last Friday evening I realized enough was enough and then wrote a 100% spot on impl of my own in about 100 lines of groovy including the templates. (Last Friday I wrote the java gen and used Lombok to make the model code really terse, to aid visibility of the model, this week python, next week the world!).

I feel there are probably a lot of folk like me thinking well there's no competition out there surely this is as good as it gets, and end up living with it for way too long. Popularity of some product doesn't always lead to it being great. We know that entropy affects software too and a pretty massive effort is needed to keep shoving a code base back up the hill to keep it clean. Bigger code bases with many cooks and without a consistently aggressive attitude to QA for the arch and the hygiene and the tests and the SDLC generally and you are toast.

Hope this helps.

dsinghvi commented 2 years ago

@Johnlon are you gonna os it?

@black-snow I am currently working on Fern which aims to improve the devx related to defining APIs and generating server/client interfaces. Fern is open source as well.

Johnlon commented 2 years ago

Yeah I really thing we need a cleaned extensible framework that's has not been hopelessly compromised by its sdlc and code quality issues. Better curation. One that isn't creaking under a mass of broken (or nonexistent) slow tests. There really isn't anything out there for oas that I want to use.

Worse tho , the oas is hopelessly inadequate in itself to describe APIs in the manner needed to generate anything other than the controller skin. Need something more expressive or just come up with a ton of OAS extensions and DIY

On Sat, 23 Jul 2022, 9:04 pm Deep Singhvi, @.***> wrote:

@Johnlon https://github.com/Johnlon are you gonna os it?

@black-snow https://github.com/black-snow I am currently working on fern https://docs.buildwithfern.com/#/ which aims to improve the devx related to defining APIs and generating server/client interfaces. Fern is open source https://github.com/fern-api/fern as well.

— Reply to this email directly, view it on GitHub https://github.com/OpenAPITools/openapi-generator/issues/7490#issuecomment-1193181411, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGMFGDLMI4C3L434ZI6B4LVVRF4HANCNFSM4RW4HS2A . You are receiving this because you were mentioned.Message ID: @.***>

cernobaiv commented 1 year ago

Hi @black-snow, your question and the further comments it gave birth to were really helpful for me to understand where I stand. You are not alone. My short story: I found it cool to have a spec-first development model and wanted to experiment with cpp-restbed-server to generate automatically the C++ restbed server stubs and hoped for using them out of the box. I already had the OAS document compiled about a year ago and used it solely to generate the html documentation, which worked fine and this gave me courage to try out the cpp-restbed-server generator as well. But ... it didn't work straight away. I also had to fight compile time issues and ran into cases, where I had to manually write the JSON serialization code as this was missing within the generated models. Then I tried to dig through the issues tracker and see maybe I could find more luck. I spotted a bug related to this, but its still open after more than 3 years. For other issues I found nothing. Sure, I can go ahead and report that or maybe contribute, but is it really worth spending the time for a generator that doesn't seem to get enough attention, but still has lots of issues? Don't mean to be rude, but I am afraid that whoever linked the size of the issue tracker to how active the developers community is here failed to present the full story. I am not sure what was the rationale behind listing the above generator within the supported ones and expose it to the github community, but I'd argue whether it is ready for that.

wing328 commented 10 months ago

@NathanFlurry thanks for informing us there's another generator/spec available out there. As we told the author of another generator in our Slack channel before, we're not against any other specifications/generators but this is not the right place to market other specifications/generators so we've deleted your message.