openapitool integration #5830
lostiniceland
started this conversation in
Development
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello everyone
I've been using the initial openapitools module and moved it over to openapitools (no PR has been filed yet).
I've added almost all configuration options (type/importmappings, partial generation, etc.), documentation, and used Maven to integrate in their pipeline. Beside the
generate
task, there is also anvalidate
on the config trait which validates the current configured spec, as well as anvalidateOpenapiSpec
command which takes a spec from the cli.There are some minor outstanding issues where I would like your opinion.
1. uTest Maven-Integration
I would like like to write some tests as well but the mill-testkit is only usable by using utest and I havent been able to figure out a way to get the uTests being recognized by JUnit or the Maven-Surefire-Plugin. Is there any way to have uTest being run from Maven?
2. SLF4J and Mill
While testing, it would have been useful to see SLF4J Logs from the Openapitools generator. Even though mill-libs pulls in slf4j-api there seems to be no integration, meaning an slf4j-mill-bridge or something similar. I've tried adding a custom implementation which allows somethings like the following
This should attach the current Task to a ThreadLocal and pipe all logs to Mill. Unfortunately I wasn't able to get this to work.
This might be caused by some dependency issues, since mill-libs-util pulls in logback-classic (which uses slf4j 2.x) but the graphviz-java dependency downgrades this to 1.7.
3. SourceFolder mappings
I've decided to pull out the property
sourceFolder
from the map which is passed to the generator to a dedicated property. This was needed because otherwise it is not always possible to create the correct source folder because the generators behave differently (some use default-values like Spring usessrc/main/java
while jaxrs-spec usessrc/gen/java
and others don't have a default). So for instance, without special handling, the Spring generator would add additional folders which breaks the classpath.In the first iteration I was just logging a warning that this folder should be set (and the map-property was used when available to create the PathRef), but I think it is better to make it explicit.
4. Test generation disabled
Openapitools by default also generates API- and Model-Tests, a feature we usually always disable, but there are probably use-cases for it. Nevertheless, I've disabled this completely because Mill doesnt distinguish between production and test sources. The only idea I had was to add another task which runs the generation again and only keeps the tests.
5. Property structure
Since Mill is plain Scala, it would be nice to group related configurations. Nevertheless, I've followed the existing Maven-/Gradle-Plugins structure/format how the properties are defined for conformance. Any thoughts on that?
Beta Was this translation helpful? Give feedback.
All reactions