OpenAPI Generator allows generation of API client libraries (SDK generation), server stubs, documentation and configuration automatically given an OpenAPI Spec (v2, v3)
[ ] [Optional] Sponsorship to speed up the bug fix or feature request (example)
Description
OpenAPI generator should generate abstract methods in interfaces. For example, the following schema clearly shows that id, type, model, and name are shared between all schemas that inherit Vehicle
However, in the resulting code we end up with an interface with only one abstract method based on the discriminator.
public interface Vehicle extends Serializable {
public String getType();
}
Desirably, this would result in an interface as follows:
any spring generation will have the same results. this is default behavior.
Steps to reproduce
Run generator on the above yaml.
Related issues/PRs
None that I can find.
Suggest a fix
Currently, we are using vendor extensions and templates to work around this issue. We have created a template called x-implements-methods, which looks as follows:
x-implements-methods:
- field: id
type: Integer
- field: type
type: String
- field: model
type: String
- field: name
type: String
and the oneof_interface.mustache now looks like this
{{>additionalOneOfTypeAnnotations}}
{{#withXml}}
{{>xmlAnnotation}}
{{/withXml}}
{{#discriminator}}
{{>typeInfoAnnotation}}
{{/discriminator}}
{{>generatedAnnotation}}
public interface {{classname}}{{#vendorExtensions.x-implements}}{{#-first}} extends {{{.}}}{{/-first}}{{^-first}}, {{{.}}}{{/-first}}{{/vendorExtensions.x-implements}} {
{{#discriminator}}
{{^vendorExtensions.x-jsontypeinfo-deduction}}
public {{propertyType}} {{propertyGetter}}();
{{/vendorExtensions.x-jsontypeinfo-deduction}}
{{/discriminator}}
{{#vendorExtensions.x-implements-methods}}
{{! begin feature: fluent setter methods}}
{{classname}} {{field}}({{>nullableDataType}}{{#lambda.titlecase}}{{type}}{{/lambda.titlecase}} {{field}});
{{! end feature: fluent setter methods}}
{{! begin feature: getter and setter methods}}
{{#lambda.titlecase}}{{type}}{{/lambda.titlecase}} {{>nullableDataType}}get{{#lambda.titlecase}}{{field}}{{/lambda.titlecase}}();
void set{{#lambda.titlecase}}{{field}}{{/lambda.titlecase}}({{>nullableDataType}} {{#lambda.titlecase}}{{type}}{{/lambda.titlecase}} {{field}});
{{! end feature: getter and setter}}
{{/vendorExtensions.x-implements-methods}}
}
We would like to see this functionality taken out of vendor extensions and added to the default behavior for when the interface is created. The beginning of this implementation is already there, since the generator is able to recognize the fields within the Vehicle schema and move them to the child objects. These fields should be saved and made accessible to the mustache templating engine directly from within the CodegenModel.java, perhaps as a field called interfaceVars.
Bug Report Checklist
Description
OpenAPI generator should generate abstract methods in interfaces. For example, the following schema clearly shows that
id
,type
,model
, andname
are shared between all schemas that inheritVehicle
However, in the resulting code we end up with an interface with only one abstract method based on the discriminator.
Desirably, this would result in an interface as follows:
openapi-generator version
6.4.0
OpenAPI declaration file content or url
Generation Details
any spring generation will have the same results. this is default behavior.
Steps to reproduce
Run generator on the above yaml.
Related issues/PRs
None that I can find.
Suggest a fix
Currently, we are using vendor extensions and templates to work around this issue. We have created a template called
x-implements-methods
, which looks as follows:and the
oneof_interface.mustache
now looks like thisWe would like to see this functionality taken out of vendor extensions and added to the default behavior for when the interface is created. The beginning of this implementation is already there, since the generator is able to recognize the fields within the
Vehicle
schema and move them to the child objects. These fields should be saved and made accessible to the mustache templating engine directly from within theCodegenModel.java
, perhaps as a field calledinterfaceVars
.