OpenAPITools / OpenAPITools/openapi-generator
[REQ] Adding 'implements' or 'extends' to a Java class without changing the OpenApi.yaml.
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 26.8k
- Forks
- 7.7k
- PR merge metrics
- PR metrics pending
Description
Is your feature request related to a problem? Please describe.
I have some Java classes, ExampleClass1 and ExampleClass2.
They are basically the same, except for a few different variables.
I would like to add an interface or a parent class to them without changing the OpenAPI.yaml.
I get the OpenAPI.yaml from a different endpoint, and I don't want to change anything there.
Describe the solution you'd like
My goal is to add an option to the config that would add an interface to specific classes.
A config like this:
addImplements: {
ExampleClass1: "com.test.project.CommonInterface",
ExampleClass2: "com.test.project.CommonInterface"
}
So, I would not have to change the original OpenAPI.yaml, and I could generate the classes with the interface automatically.
Describe alternatives you've considered
An alternative would be to use a config to add an external parent.
addExtends: {
ExampleClass1: "com.test.project.CommonParent",
ExampleClass2: "com.test.project.CommonParent"
}
Additional context
Some Examples:
my OpenAPi.yaml
// 20231004115458
// http://localhost:8084/v3/api-docs
{
"openapi": "3.0.1",
"info": {
"title": "OpenAPI definition",
"version": "v0"
},
"servers": [
{
"url": "http://localhost:8084",
"description": "Generated server url"
}
],
"paths": {
"/exampleClass2": {
"post": {
"tags": [
"basic-controller"
],
"operationId": "postDataForm",
"requestBody": {
"content": {
"application/x-www-form-urlencoded": {
"schema": {
"$ref": "#/components/schemas/ExampleClass2"
}
}
},
"required": true
},
"responses": {
"200": {
"description": "OK",
"content": {
"*/*": {
"schema": {
"$ref": "#/components/schemas/ExampleClass2"
}
}
}
}
}
}
},
"/exampleClass1": {
"post": {
"tags": [
"basic-controller"
],
"operationId": "postDataForm_1",
"requestBody": {
"content": {
"application/x-www-form-urlencoded": {
"schema": {
"$ref": "#/components/schemas/ExampleClass1"
}
}
},
"required": true
},
"responses": {
"200": {
"description": "OK",
"content": {
"*/*": {
"schema": {
"$ref": "#/components/schemas/ExampleClass1"
}
}
}
}
}
}
}
},
"components": {
"schemas": {
"ExampleClass2": {
"type": "object",
"properties": {
"version": {
"type": "string"
},
"id": {
"type": "integer",
"format": "int32"
},
"exampleDouble": {
"type": "number",
"format": "double"
}
}
},
"ExampleClass1": {
"type": "object",
"properties": {
"version": {
"type": "string"
},
"id": {
"type": "integer",
"format": "int32"
},
"somethingDifferent": {
"type": "string"
}
}
}
}
}
}
/**
* ExampleClass1
*/
@Generated(value = "org.openapitools.codegen.languages.SpringCodegen")
public class ExampleClass1 {
private String version;
private Integer id;
private String somethingDifferent;
...
}
/**
* ExampleClass2
*/
@Generated(value = "org.openapitools.codegen.languages.SpringCodegen")
public class ExampleClass2 {
private String version;
private Integer id;
private Double exampleDouble;
...
}
How i want them to be generated:
public class ExampleClass1 implements CommonInterface {
...
}
public class ExampleClass2 implements CommonInterface {
...
}
Or as Parent
public class ExampleClass1 extends CommonParent{
...
}
public class ExampleClass2 extends CommonParent{
...
}
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No source files, tests, or entry points are identified in the issue. Start by locating the Java generator's configuration handling and model-class generation path, then define how per-class implements or extends settings should be represented and validated; done means generated classes include the requested relationship without requiring changes to the OpenAPI document.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java, openapi
- Domain
- backend-api-design, devtools
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100