[BUG][Kotlin Client] API using case other than camelCase not generated properly

[lemoinem]

PR checklist

• Read the contribution guidelines.
• Ran the shell script under ./bin/ to update Petstore sample so that CIs can verify the change. (For instance, only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh, ./bin/security/{LANG}-petstore.sh and ./bin/openapi3/security/{LANG}-petstore.sh if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in .\bin\windows\.
• Filed the PR against the correct branch: master, 3.4.x, 4.0.x. Default: master.
• Copied the technical committee to review the pull request if your PR is targeting a particular programming language. (/cc @jimschubert @dr4ke616)

Description of the PR

Generating from a json file, if an API uses anything other than camelCase, the property names are not generated with the proper Json name. The generated code does not serialize/deserialize properly.

Adding a @Json annotation on the properties fixes it.

[jimschubert]

Thanks for the PR. I think we had similar code before but it was removed. I may be remembering another generator, so I'll need to do some investigation. If memory serves, the issue was that it removes the possibility of xml support.

I'll try to do some digging tonight or tomorrow, unless someone else on the core team remembers the scenario.

[lemoinem]

Please note that the Kotlin client code, only support JSON serialization and deserialization (see https://github.com/OpenAPITools/openapi-generator/blob/master/modules/openapi-generator/src/main/resources/kotlin-client/infrastructure/ApiClient.kt.mustache#L33-L68)

In the case where we do choose to implement XML support (which is out of scope for this PR), I'm still having a hard time understanding how adding a Moshi (which is only a JSON serializer) annotation could prevent XML Support.
If the interaction actually exists, I'd prefer we find a way around it once we've settled on a concrete XML serializer. requiring APIs to use camelCase is a pretty strong requirement IMO. Especially without documentation, warnings, error or exception thrown. It took me quite a while to realize this was the issue.

I noticed the circleci tests failed because of the missing imports for the annotation. I've fixed this in a new commit plus the new line issue.

[jimschubert]

@lemoinem I searched through history in this project and swagger-codegen, and I couldn't find the code I was remembering. It must have been an issue from another generator that I was remembering. You're correct that Moshi is JSON only, which I should've realized immediately that what I was thinking about couldn't have been related to this PR!

This is good to merge once the builds pass.

[lemoinem]

Thanks! Glad we agree!

If you can confirm which output you prefer (@Json on its own line or together with the var), I'll change that and fix the CircleCI check ASAP.

[jimschubert]

@lemoinem Sorry for taking a bit to respond. I personally prefer the oneliners, but in this case I would stick with the official Kotlin style guide: https://kotlinlang.org/docs/reference/coding-conventions.html#modifiers. Basically it says only single annotations without parameters should go on the same line, all others go above.

My point previously was mainly about the additional newlines, though. In generated code, people often consider large "unconventional" spacing to be an indicator that something didn't get generated as expected. It can sometimes be a pain with mustache and newlines at the ends of files, so no worries if the whitespace remains.

[lemoinem]

I've fixed the templates to match the style guide for annotation (for all templates, just so it's consistent).
I've also updated the code samples generated from the templates. This should fix the build.

[jimschubert]

Shippable failure was unrelated to this PR. I've retried the build.

[lemoinem]

Great, thanks!