pwall567 / json-kotlin-gradle

Gradle JSON Schema code generation plugin
17 stars 7 forks source link

Help with requirements for generating Kotlin classes #3

Open PrakharR opened 2 years ago

PrakharR commented 2 years ago

I have a few requirements for converting existing JSON schema to Kotlin classes in my organization that I thought I’d raise here. I couldn’t find an immediate solution for them and wanted to see if you have any suggestions?

  1. Add @Serializable as an annotation to all generated classes.
  2. Have a generated class implement an existing interface.
  3. Force a property to use Map<Any, Any> as a type.

Both 2 and 3 are possible using the jsonschema2pojo library that my organization is currently using to generate POJOs. Using javaInterfaces for 2 and existingJavaType for 3. I believe these are not standards in the JSON Schema (Draft 07) so I understand if these are not something that are currently possible and won't be part of the plan for your repos.

It’s possible that the json-kotlin-schema-codegen or json-kotlin-schema libraries may be a better place for asking you about these requirements, but I wanted to open just one issue for easier communication.

Your libraries have been very useful, thank you for creating them!

pwall567 commented 2 years ago

Thanks for the feedback!

Taking your points one at a time:

  1. Add annotation to all generated classes: One of the main policy decisions behind the code generator was to make the generated code as simple as possible, allowing it to be used with a minimum of external dependencies. That included the decision not to add annotations to the generated code. It would be possible to provide some means of specifying annotations to be added at nominated points, but it would take a certain amount of effort and I haven't seen any demand for it until now.
  2. Have a generated class implement an existing interface: It is possible to specify what is referred to as a "marker interface" to the CodeGenerator class when used programmatically, but this functionality is not available through the config file. I'm not aware that this is widely used, but I can certainly add it to the config file mechanism.
  3. Force a property to use Map<Any, Any> as a type: The config file provides a mechanism for specifying a nominated class for any generated property - see customClasses in the config file documentation. This only allows the use of a simple class (not a parameterised type), but it is possible to add a typealias such as typealias MapAnyAny = Map<Any, Any> in a separate file, and then use the simple name in the config file.

I appreciate the suggestions, and I will keep all of this in mind when thinking about ongoing development.