-
-
Notifications
You must be signed in to change notification settings - Fork 6.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[REQ] Support for OpenAPI Spec 3.1 #9083
Comments
We use swagger-parser to parse openapi specs. That project must implement v 3.1 spec parsing before we can implement it in the generators. |
This reverts commit 247d726.
Any updates to share on potentially updating the generators to OAS 3.1? |
swagger-api/swagger-parser#1535, there has been no update for half a year. |
OAS 3.1 support has been added to swagger-parser in swagger-api/swagger-parser#1730 |
What release do you aim for this to be implemented in the generator? 6.1.0? |
swagger-parser 2.1 has been released with OAS 3.1 support |
This is a big oof on my part. I just spent a ton of time setting up an API spec for a client and used 3.1.0 and now that its all approved I need to actually program the API server and need to generate the base files from the spec. Now I find out that not only does this package not support 3.1.0 currently but I cannot seem to find any code generator that does :( big yikes! I have to figure out what my options are at this point as my spec currently makes heavy use of the I see that as of |
We are also waiting for this feature, to generate classes from components if there is no API (e. g. publish Kafka Event Objects as Open Api Spec). I hope there will be soon a new release for that. |
Any updates on 3.1 support? |
This is a huge impediment. I too have an API that relies on 3.1 features. It seems to be taking the toolchain a very long time to support it. |
Type null works with 3.0.3 specs and our tool |
Hello! As the maintainer of openapi.tools, and as somebody works with Linux Foundation helping out in OpenAPI-land, I'm reaching out to tooling vendors to track the progress towards supporting OpenAPI v3.1, to see what roadblocks there are beyond folks just generally being busy at this ridiculous time. OpenAPI v3.1 has a bunch of great little changes, solving problems like the JSON Schema <!=> OpenAPI Schema Object divergence. It also fixes some other inconsistencies and duplicate ways of doing things. It's the best version and everyone should be using it, but we need tooling to catch up. Just in case folks didn't notice, or don't have resources to simplify the process, I'm here to give a friendly prod and send over some handy links. Here are a few articles showing off the differences between OpenAPI v3.0 and v3.1.
Here are some example files which can make for handy pass/fail test cases: https://github.com/Mermade/openapi3-examples/tree/master/3.1 If you're looking for the JSON Schema that defines a valid OpenAPI document, that'll be right over here: https://github.com/OAI/OpenAPI-Specification/tree/main/schemas/v3.1 No rush, but when you're starting work on it, please update this issue so I can update openapi.tools to reflect that, and folks will have a way to subscribe for updates. LMK if you have any questions! |
Apart from the actual lack of 3.1 support the biggest issue I have is that this project does not seem to be open about it. The README doesn't mention it. https://openapi-generator.tech/ prominently claims
which led me to believe that 3.1 be fully supported. |
Probably should say 3.0.x... |
It would be helpful to see an itemized list of what is still needed to achieve v3.1 support, so that members of the community can help out. Has anyone identified those tasks? |
I am putting together that list now and we will publish a project very soon. This is something that we all want to add to openapi-generator. It is ~30 feature additions to store the new openapi/json schema data in our java classes. Then that data needs to be used by the generators to generate code that imposes the new json schema validation + adds new openapi features. |
We have a project to track adding 3.1.0 support here: Generators that will have 3.1.0 support prioritized: Tag for 3.1.0 issues/PRs: |
@philsturgeon one big roadblock is that there are a number of bugs in swagger-parser that prevent json schema test cases from running/passing. One can see 10 of those bugs here: https://github.com/swagger-api/swagger-parser/issues?q=is%3Aissue+is%3Aopen+3.1.0+author%3Aspacether |
@spacether I'm sorry to say I've got absolutely nothing to do with https://github.com/swagger-api/swagger-parser. You're mistaking it for https://github.com/APIDevTools/swagger-parser, which I do occasionally maintain, but it's is a whole other thing. |
Just answering your |
OpenAPI v3.1.0 python code generation is now supported in openapi-json-schema-generatorHeads up, I just released v3.3.0 of openapi-json-schema-generator which allows python code generation using an openapi v3.1.0 document. Over 66% of the 3.1.0 new json schema keyword features have been implemented
|
@adampoplawski @phillipuniverse I have been working on a Java generator and v3.0.0-v3.0.3 openapi schema validation has been implemented in java. This includes List/Map output classes, List/Map builder classes, and Enums which are accepted into Schema.validate and the List/Map builders. Read all about it here. The Java schema validation is available in my v4.0.0 release. |
Hi, When can we expect the openapi specification version 3.1.0 to be supported by the OpenAPI-Generator tooling? Is there any roadmap we can reference to keep an eye on? Thanks |
latest stable version v7.2.0 comes with beta support. you can give it a try to see if it works for your use cases. |
Thanks @wing328 - will give it a shot. |
openapi v3.1.0 schema support added for java in openapi-json-schema-generatorHeads up, I just released v4.1.0 of openapi-json-schema-generator which allows java code generation using an openapi v3.1.0 document. Over 67% of the 3.1.0 new json schema keyword features have been implemented
|
@wing328 Can you share the status of 3.1.0 support? |
The best way to get updates regarding OpenAPI 3.1 support (beta) is via the Label in the pull request tab: https://github.com/OpenAPITools/openapi-generator/pulls?q=+is%3Apr+label%3A%22Feature%3A+OAS+3.1.0+spec+support%22+ |
openapi 3.1.0 support added for the java generator in openapi-json-schema-generatorHeads up, I just released v4.2.1 which includes the stable java sdk generator
|
@wing328 you mentioned that beta 3.1.0 support is available, but i can't see any information about enabling this support? can you please provide more details? |
As complete OpenAPI 3.1 support doesn't seem to come soon, I would like to understand what the current state is. Wouldn't it make sense to document somewhere what experimental means and which features should working correctly? |
@jahlbornG it's automatic. if your spec is documented as 3.1.0, it will enable the beta support. v7.7.0 was released last week. please give it a try as it includes more fixes for v3.1.0 spec |
The enabling is not the question, my question is what to expect? What does beta mean? Should I expect all features to be there and just not as solid as 3.0? |
@wing328 i am using the generator maven plugin to convert a swagger (2.0) document to an openapi spec document. it seems to generate 3.0.1 by default, and i'd love to get it to generate 3.1.0. |
Is there a roadmap for the full support for 3.1? There is a project https://github.com/orgs/OpenAPITools/projects/4/views/1 that tackles this but there haven't been any changes since january |
It would be great if openapi-generator tackled the issue that properties in model classes are generated with Object type instead of String, Integer, etc. #15203 |
@wing328 what's the process of reporting issues encountered while building 3.1 specs? Should I raise a separate issue or sth else? |
yes please |
Is your feature request related to a problem? Please describe.
Support for OpenAPI Spec 3.1, released last month: https://github.com/OAI/OpenAPI-Specification/releases/tag/3.1.0
Describe the solution you'd like
Add support for OpenAPI Spec 3.1
Additional context
Couldn't see any other mention of this besides a short mention in #15
Another note on https://www.openapis.org/blog/2020/06/18/openapi-3-1-0-rc0-its-here which mention that the specification-change is bigger than it sounds and might break some tooling.
The text was updated successfully, but these errors were encountered: