Bug Report Checklist
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:
public interface Vehicle extends Serializable {
// Builder methods
Vehicle id();
Vehicle type();
Vehicle model();
Vehicle name();
// Getters
Integer getId();
String getType();
String getModel();
String getName();
// Setters
void setId(Integer id);
void setType(String type);
void setModel(String model);
void setName(String name);
}
openapi-generator version
6.4.0
OpenAPI declaration file content or url
components:
schemas:
Vehicle:
type: object
required:
- id
- type
properties:
id:
type: integer
type:
type: string
model:
type: string
name:
type: string
oneOf:
- $ref: '#/components/schemas/Car'
- $ref: '#/components/schemas/Plane'
discriminator:
propertyName: type
Car:
type: object
properties:
type:
enum:
- car
has_4_wheel_drive:
type: boolean
Plane:
type: object
properties:
type:
enum:
- plane
has_reactor:
type: boolean
nb_passengers:
type: integer
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:
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, andnameare shared between all schemas that inheritVehicleHowever, 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.mustachenow 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
Vehicleschema 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.