Feature Description
(This issue may apply equally to plain swagger-maven-plugin, I haven't tested)
By default the plugin does not understand Kotlin well:
- non-nullable fields are not automatically listed as required.
- field names starting with 'is' will lose their prefix in the doc, which is simply wrong.
- there may be other discrepancies
I would like a solution to this that requires as little effort and awareness as possible of the developer.
Use Case
I want to write my endpoints and dtos in standard kotlin, with as little though as possible to the quirks of my documentation tool, and for the plugin to extract as much knowledge as possible from the code before needing annotations.
Suggested Solution (optional)
The solution should leverage jackson's kotlin module, which understands all the problematic cases well.
Some implementation alternatives - in order of prefence:
- The plugin uses kotlin-module by default for Kotlin classes
- A separate plugin is provided that supports Kotlin
- A simple config option for enabling Kotlin support
- Include a ready-made KotlinAwareObjectMapperProcessor that just needs to be configured i the pom
Alternatives Considered
- The standard solution is to provide the plugin with a custom objectMapperProcessorClass that registers jackson's kotlin module to the mapper. This is a small task and works well, but feels unnecessary (especially writing the processor yourself), and more importantly:
- You get no hint that you need to do this, until someone discovers the docs are wrong.
- Explicit tagging can fix it, but it is not intuitive that you need to, since the information is right there in the code. Even when you know, it is easy to forget, and the resulting error is hard to spot.
Checklist
Feature Description
(This issue may apply equally to plain swagger-maven-plugin, I haven't tested)
By default the plugin does not understand Kotlin well:
I would like a solution to this that requires as little effort and awareness as possible of the developer.
Use Case
I want to write my endpoints and dtos in standard kotlin, with as little though as possible to the quirks of my documentation tool, and for the plugin to extract as much knowledge as possible from the code before needing annotations.
Suggested Solution (optional)
The solution should leverage jackson's kotlin module, which understands all the problematic cases well.
Some implementation alternatives - in order of prefence:
Alternatives Considered
Checklist