We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
I'd like to suggest another solution for handling conflicting class names when generating POJOs from example JSON files.
Looking at this example BaseData.json:
{ "office": { "contact": { "street": "Some Street", "houseNumber": "42", "town": "Some Town", "phoneNumber": "0118 0", "email": "office@somebusiness.tld" } }, "emergency": { "contact": { "phoneNumber": "0118 999 881 999 119 7253" } }, "press": { "contact": { "phoneNumber": "0118 1", "email": "press@somebusiness.tld" } } }
I end up getting classes named BaseData, Emergency, Office, Press, Contact, Contact_1 and Contact_2.
BaseData
Emergency
Office
Press
Contact
Contact_1
Contact_2
I'd better prefer to have the latter three classes named OfficeContact, EmergencyContact and PressContact.
OfficeContact
EmergencyContact
PressContact
In order not to break existing projects this should be an option like combineClassNamesOnCollusion (default false)
combineClassNamesOnCollusion (default false)
Implementation might be more lightweight than #125 I guess.
The text was updated successfully, but these errors were encountered:
No branches or pull requests
I'd like to suggest another solution for handling conflicting class names when generating POJOs from example JSON files.
Looking at this example BaseData.json:
I end up getting classes named
BaseData
,Emergency
,Office
,Press
,Contact
,Contact_1
andContact_2
.I'd better prefer to have the latter three classes named
OfficeContact
,EmergencyContact
andPressContact
.In order not to break existing projects this should be an option like
combineClassNamesOnCollusion (default false)
Implementation might be more lightweight than #125 I guess.
The text was updated successfully, but these errors were encountered: