I'm having problems with the OpenAPI java generator when having a definition which is containing a schema like (unfortunatly I get this definition from 3rd party)
"ExtendedBasicdata": {
"type": "object",
"properties": {
"ExtendedBasicData": {
"type": "array",
"items": {
"$ref": "#/definitions/Extendedbasicdata"
}
}
}
},
"Extendedbasicdata": {
"type": "object",
"properties": {
"ID": {
"type": "string"
},
"Country": {
"type": "string"
}
}
},
"objects": {
"type": "object",
"properties": {
"id": {
"type": "string"
},
"label": {
"type": "string"
},
"entityId": {
"type": "string"
}
}
},
The first problem is that the 2 objects ExtendedBasicdata and Extendedbasicdata have the only difference in the case. The generator only creates a java file with name Extendedbasicdata but with classname ExtendedBasicdata which results in error Class 'Extendedbasicdata' is public, should be declared in a file named 'Extendedbasicdata.java'. Is there any possibility to make the generator case sensitive?
The second problem is that generator is importing java.util.Objects; by default and therefor a class Objects cannot exist. Is there a way to override the name during generation?
Your ExtendedBasicdata class contains an arrayList of Extendedbasicdata called ExtendedBasicData. It sounds like you are hoping for something like this.
public class ExtendedBasicdata {
private List<Extendedbasicdata> ExtendedBasicData;
}
As the title of this section says, "Don't do this". This is horrible design, and as another commenter said, it is also very error prone. I'm also going to assume that you made these names for the purpose of the question and that they aren't actually the names used, just the same basic concept.
Second, property names should be named in camelCase. This is just a standard naming convention. However, the generator also knows this and converts the field names to camelCase for you.
Finally, to actually answer your question, you can definitely affect the way the names are generated via the mustache templates. Specifically, you can identify the classes and methods you want and apply a lambda to them to change their case.
As for the issue with Objects, you can also modify all of the templates to use the fully qualified path name of Objects and delete the import.
For example, in the model.mustache, you can delete the line import java.util.Objects; And in pojo.mustache, modify line311 to use the fully qualified name. So, it would look like this.
return a == b || (a != null && b != null && a.isPresent() && b.isPresent() && java.util.Objects.deepEquals(a.get(), b.get()));
You would have to delete every single import statement in every mustache template, and fully spell out the path at every implementation of Object throughout the code. This is a lot of work that could easily be fixed by renaming your property.
I want to reiterate that I don't recommend doing any of this. I understand that you are using a 3rd party api, but if that is true, and this is just a small example of their api, I can only imagine what other problems exist in it.
One option is to use your own api definition, and reference the other definition when it is needed. For example,
RenamedFromExtendedBasicData:
type: object
properties:
anotherNewName:
type: array
items:
$ref: './bad3rdpartyspecification.yaml#/definitions/Extendedbasicdata`
This allows you to use good naming conventions while still relying on the other specification for the objects that matter.