Kotlin support

[stephan-strate]

trafficstars

It would be amazing to have Kotlin support for this extension. Main advantages would be the pojos with nullability for types and coroutines for reactive implementations.

Maybe we could discuss a way to integrate it.

Happy to contribute.

[ricardozanini]

Hi!

I think it won't take too much effort to implement this if someone with Kotlin knowledge would create the templates. A codegen property to select the language and keep Java by default should do the trick. Then, in the generator, we load one set of templates or another. Remember that everything we do in the Java templates, we should do in Kotlin.

If you take this endeavor, I would ask you to be around to do the implementations in the Kotlin templates. Otherwise, depending on the community's push for more features that impact the templates, it can be deprecated soon.

[stephan-strate]

I will try to get a draft working and submit it as pr.

[github-actions[bot]]

@ricardozanini @hbelmiro This is being closed due to inactivity.

[ygyg70]

Any update/insight on this topic would be greatly appreciated 👍

[ricardozanini]

@ygyg70 we are accepting contributions since the maintainers don't have bandwidth at the moment.

[laurentperez]

I might attempt this but it depends on the time effort required, and questions below. @stephan-strate or @ricardozanini : TBH how much effort do you think it would require : is it, maybe in the 20-40 hours range ?

Also, is RESTeasy classic an optional scenario or would we want RESTeasy reactive only ? Asking because there are still people based on the classic stack. Yes Quarkus sort of "deprecated" the classic, I mean, reactive is favored over classic.

But if we go reactive only, two sets of HTTP properties would be required in application.properties : the classic ones for the "old" classic stack which may be present in a production project which does not want to go reactive all the way, and the reactive ones, pulled by the extension - if the extension chooses the reactive implementation

When you boot up a quarkus code starter bundling both classic and reactive artefacts it produces - rightfully so - warnings on boot telling that one should be preferred over the other.

I'm not sure what implementation choice other HTTP extensions selected. Did they just forget the classic side ?

[ricardozanini]

I'd say to invest effort in reactive, and in the long run we can add classic if needed and required by our community.

[github-actions[bot]]

@ricardozanini @hbelmiro This is being labeled as Stale.

[github-actions[bot]]

@ricardozanini @hbelmiro This is being closed due to inactivity.

[jan-rohac-kosik]

Hi!

I think it won't take too much effort to implement this if someone with Kotlin knowledge would create the templates. A codegen property to select the language and keep Java by default should do the trick. Then, in the generator, we load one set of templates or another. Remember that everything we do in the Java templates, we should do in Kotlin.

If you take this endeavor, I would ask you to be around to do the implementations in the Kotlin templates. Otherwise, depending on the community's push for more features that impact the templates, it can be deprecated soon.

Hi @ricardozanini, I've prepared the Kotlin templates you asked for. They are not tested. I can test them when the codegen is ready to use them. https://github.com/jan-rohac-kosik/quarkus-openapi-generator/tree/issue-134-kotlin-support