-
-
Notifications
You must be signed in to change notification settings - Fork 6.6k
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
[BUG] OneOf java classes not getting generated as part of codeGen in gradle plugin 4.0.0 #2906
Comments
I'm mentioning this in case it's a problem with the underlying spec parsing rather than the language generator. This is in my spec for a response object property: "currentAuthorisation": {
"oneOf": [
{
"$ref": "#/components/schemas/simpleAuthorisation"
},
{
"type": "string",
"nullable": true,
"description": "null if there is no current authorisation"
}
]
}, The class not being generated is |
For Java, I'm hitting the same issues using both the CLI and the gradle plugin: Oneof classes are not generated. |
Facing the same problem with the java maven plugin: OneOf* classes are not generated, hence failing the compile task in the maven build. |
Same issue here. |
Same here. |
so when is this going to be resolved? I am using the latest openapi-generator and I too get this issue. luckily I am doing the design of the API so I can redesign my API to NOT use oneOf to avoid this. but i will love very much to implement oneOf as some of my APIs are designed to return different object types depending on the input. |
do we know when is it going to be resolved? |
Same for me for generating Java server. |
Same issue here. This is a critical blocker for using openapi generator in our project as we deal with polymorphic APIs. Has anyone at least found a workaround for this? |
A workaround is to create those classes manually. |
any examples on how these classes should look like..? |
Depends on your setup. We just extend one of the classes that it generated as the parent of the ones we need, then implement all of the unique parts. That will look like the class we need. |
I'm having the same issue with the jaxrs-cxf generator. Currently we are using the version 3.3.4. There the OneOf... Class doesn't get rendered. Instead Object is used. This works for our use case. |
Same issue with a JHipster API-first development project, which uses: |
It has seemingly fixed by this PR #5120 |
We are using the openapi-generator-gradle plugin to do the generation, and seeing this issue too with version 4.3.0. Tried the 5.0.0-beta version (released June 2020) and still seeing this issue, so either that merge didn't make it in to either version, or it is not fixed. |
Im having some issue... using openapi-generator-maven-plugin at 4.3.1 version. So do u have any updates regarding this issue? The merge was really made? |
Currently, only |
@wing328 I have tried using the
The generated
Any ideas? |
I think we also had some import problems, but I'm not sure, as I'm not the one directly working with these. |
A (not type-safe) workaround is to enumerate the class names generated from oneOf types in the following command line switches when running the generator: |
In 7.8.0, it is generating both classes for OneOf, means this is fixed ? |
When I generate sever stub for spec having OneOf tags, the code generation gradle task is successful , but in the generated models package OneOf*.java classes are missing.
I am using org.openapitools:openapi-generator-gradle-plugin:4.0.0 for "jaxrs-jersey" generatorName.
For example for below YAML file class "OneOfSofa1Sofa2" is not getting generated , but it is referred for variable "sofaStyle" in generated class Home.java
I have attached the YML as txt
home.txt
Below gradle task was used:
openApiGenerate { generatorName = "jaxrs-jersey" inputSpec = "$rootDir/src/main/resources/home.yml".toString() outputDir = "$rootDir".toString() apiPackage = "com.home.rest.resources" invokerPackage = "com.home.rest" modelPackage = "com.home.rest.model" modelFilesConstrainedTo = [] configOptions = [ dateLibrary: "java8" ] }
Screenshot of how it looks in editor
The text was updated successfully, but these errors were encountered: