New feature: OpenAPI generator for kotlin #1254
Conversation
# Conflicts: # openapi-generator/src/main/java/io/micronaut/openapi/generator/JavaAbstractMicronautCodegen.java # openapi-generator/src/test/java/io/micronaut/openapi/generator/MicronautClientCodegenTest.java
# Conflicts: # openapi-generator/src/main/java/io/micronaut/openapi/generator/JavaAbstractMicronautCodegen.java # openapi-generator/src/test/java/io/micronaut/openapi/generator/MicronautClientCodegenTest.java
altro3
changed the title
altro3
force-pushed
the
generator-kotlin
branch
from
e286dcb
to
78f2986
Compare
|
@graemerocher don't know how to fix binary comatibility problems. Also I found bug with micronaut-core for kotlin - optional QueryValues are always required. And validation doesn't work for controller parameters |
altro3
force-pushed
the
generator-kotlin
branch
4 times, most recently
from
7393848
to
1675076
Compare
altro3
force-pushed
the
generator-kotlin
branch
from
1675076
to
d1bbfef
Compare
# Conflicts: # openapi-generator/src/main/java/io/micronaut/openapi/generator/AbstractMicronautJavaCodegen.java # openapi-generator/src/test/java/io/micronaut/openapi/generator/JavaMicronautClientCodegenTest.java
|
@andriy-dmytruk @graemerocher please, look to this. Generator wotks fine, but some tests with validation now disabled, because this is a bug of core or validation library. But code generator for kotlin works fine |
test-suite-kotlin-server-generator/src/main/java/io/micronaut/openapi/test/filter/MyFilter.java
Outdated
Show resolved
Hide resolved
...lin-server-generator/src/main/java/io/micronaut/openapi/test/api/ResponseBodyController.java
Outdated
Show resolved
Hide resolved
...tlin-server-generator/src/main/java/io/micronaut/openapi/test/api/RequestBodyController.java
Outdated
Show resolved
Hide resolved
...otlin-server-generator/src/main/java/io/micronaut/openapi/test/api/ParametersController.java
Outdated
Show resolved
Hide resolved
| {{#model}} | ||
| {{^vendorExtensions.x-is-one-of-interface}} | ||
| {{^isEnum}} | ||
| val model: {{classname}}? = null |
There was a problem hiding this comment.
if this is injected would be better as a constructor argument
There was a problem hiding this comment.
Can' t do it
Initialization exception. Must be single constructor, but we have 2 constructors
| {{>common/generatedAnnotation}} | ||
| {{/generatedAnnotation}} | ||
| @EachProperty("security.basic-auth") | ||
| open class HttpBasicAuthConfiguration @ConfigurationInject constructor( |
There was a problem hiding this comment.
can be made a data class in which case @ConfigurationInject is not needed
| @Target(FUNCTION) | ||
| @Bindable | ||
| @Repeatable | ||
| annotation class Authorization( |
There was a problem hiding this comment.
in general I am wondering why we don't upstream more of this annotation/filter logic
There was a problem hiding this comment.
I don't know, that's what was in the java generator. I just converted this to kotlin
|
@graemerocher about you question: I don’t see any problems with generating code in Kotlin, but implementing interfaces in Java. I fixed what you didn't like - now all tests for Kotlin are written in Kotlin. But! Thanks to the fact that I initially wrote tests in Java, I was able to find validation bugs if I mixed Java and Kotlin in one project. I’m not sure if this is popular, but I don’t understand why some of the methods work correctly, while others give errors in this case |
altro3
force-pushed
the
generator-kotlin
branch
from
ddd9746
to
5b23e62
Compare
|
I feel like there is too much duplication between Kotlin & Java. |
|
@andriy-dmytruk I did this on purpose for a specific reason: I don’t want the generator code for Kotlin to affect an already existing generator for Java (the same is done in the openapi generator itself). Yes, there are duplicates, but you can be sure that if you correct the logic for Kotlin, you will not change the logic for Java and vice versa. Unfortunately, no solution will be perfect. Excessive unification always leads to more complex code and potential problems in the future. |
|
@andriy-dmytruk @graemerocher Could you merge it? |
|
@altro3 Thanks for the contribution again. I think you can probably do a release, you don't need to wait for 4.2 |
No description provided.