JavaFileGenerator in the generate models command ONLY generates the java model classes correctly if the openapi specs follow the java naming conventions

[oliverkuntze]

Describe the bug

At the moment the JavaFileGenerator in the generate models command ONLY generates the java model classes correctly if the openapi specs follow the java naming conventions.

For example if a schema in the openapi spec contains a property myID the generate models java command will generate a property myId in the corresponding class.

We cannot assume that authors of asyncapi specs strictly follow the rules of java naming conventions.

We should assure that all openapi specs can be correctly generated into java model classes independent of following java naming conventions when writing the specs or not.

Description

In https://github.com/asyncapi/cli/blob/master/src/commands/generate/models.ts the JavaFileGenerator currently is instantiated this way:
fileGenerator = new JavaFileGenerator();

The JavaFileGenerator should be instantiated this way:
fileGenerator = new JavaGenerator({ presets: [JAVA_JACKSON_PRESET] });

This way the schema properties not following the java naming conventions would annotated with the corresponding JsonProperty annotations.

This won't be a breaking change other than one has to add the jackson-annotations dependency to one's project.

How to Reproduce

Take any asyncapi spec with schema properties that are not written in camel case and run the cli with generate models java.
Have a look at the model classes to find all non camel case schema properties converted to camel case java properties, thus breaking the contract.

Expected behavior

Since asyncapi does not enforce the usage of java compliant naming conventions for the schema properties in their specs it should correctly generate model classes for specs that don't follow the java naming conventions.

[github-actions]

Welcome to AsyncAPI. Thanks a lot for reporting your first issue. Please check out our contributors guide and the instructions about a basic recommended setup useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

[oliverkuntze]

If it helps I could do the coding myself and provide a pr.
Fixing this bug would allow me to integrate asyncapi as nicely as openapi in my gradle builds.

[Athul0491]

@oliverkuntze
I've added a PR for this, any feedback is welcome. Thanks!

[oliverkuntze]

Great news. Thank you, @Athul0491 !

Can't wait for the release. :-)

In the PR:
Is the
presets.push({ preset: JAVA_COMMON_PRESET, options }
needed for javaJackson and javaConstraints?

Cheers
Oliver

[asyncapi-bot]

🎉 This issue has been resolved in version 1.3.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[oliverkuntze]

@Athul0491 , could it be that I was right with the remark that
presets.push({ preset: JAVA_COMMON_PRESET, options }
probably was incorrect for javaJackson and javaConstraints?
Activating for example the javaJackson option yields code that cannot be compiled since duplicate methods for equals, hashCode, toString and toIntendedString are generated.
Is my understanding correct that JAVA_COMMON_PRESET is responsible for the generation of these methods?
Looking at the code JAVA_COMMON_PRESET is pushed TWICE to presets. That would explain the duplication of the methods.

[Athul0491]

@oliverkuntze now that i look at the PR again, i realize that you are right. I'll push the changes asap! Pretty sure the same problem exists for TS as well.

[oliverkuntze]

Perfect! Thanks @Athul0491 ! We are really eager to use the feature. :-)

[asyncapi-bot]

🎉 This issue has been resolved in version 1.4.2 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀