-
-
Notifications
You must be signed in to change notification settings - Fork 6.3k
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
[Java] "allOf" no longer supports inheritance AND composition #1358
Comments
Ref: minimal spec to reproduce the issue: https://gist.github.com/clintfoster/d60b4da3f7b1249bf8c765dfb202bbc0 |
#1360 has been merged into master. Please give it another try and let us know if it's still an issue. Closing this issue for the time being. |
Thank you! I will test with the next |
Next release is 4.0.0 (tentatively scheduled on Jan 30th) |
Confirmed fix in One anomaly: The following console warning is still emitted, even though the additional inline schemas beyond the first are "composed" (not ignored), as expected:
|
Is there a way to avoid this warning? I use version 4.2.2 |
Description
I just attempted to migrate from swagger-codegen to openapi-generator. It was mostly successful, except the behavior of
allOf
has changed. Previously the generated Java class would inherit from the first$ref
and compose from the rest. With the new generator the Java class still extends the first$ref
, as expected. But all the other$refs
are ignored. (Their fields are no longer composed directly into the Java class.)openapi-generator version
I am using the new Gradle plugin:
openapi-generator-gradle-plugin:3.3.2
(much appreciated).This previously worked with
swagger-codegen-cli:3.0.2
. In case you're wondering, since there is no official Gradle plugin I was using thisorg.hidetake.swagger.generator
, which wraps the CLI as a Gradle plugin.OpenAPI declaration file
See comments next to each
$ref
:Note:
FooBase
has a discriminator. The composed models do not:Command line used for generation
build.gradle excerpt
config file
Suggest a fix/enhancement
The Java generator should support single inheritance, plus an arbitrary number of composed models, as it did before. This allows a great deal of flexibility. For example, I have models representing "views" returned to clients consisting of a database record that extends a base model, plus fields composed from other models. The client need not know which fields came directly from the db record, and which are calculated on-the-fly and returned from other models.
The text was updated successfully, but these errors were encountered: