Quarkus: Create Kotlin compiler plugin for open classes

[geoand]

We should create a Kotlin compiler plugin that will stand in place of the all-open plugin and will contain pre-configured all the annotations that result in classes that must not be final (much the same way that the Kotlin spring does).
This will also solve this issue.

[geoand]

I can do this once Quarkus goes live.
@mkouba were would I see which annotations result in creating dynamic proxies?
I mean I can always brute force by trying them and seeing what fails, but if there was somewhere were that info is gathered, then it would save me the trouble :)

[mkouba]

In general we need to create a client proxy for normal scoped beans (@ApplicationScoped, @RequestScoped atm) and we also create a subclass for any intercepted bean. So in theory, you should "open" any class/members declared on a class annotated with a normal scope or with an interceptor binding. That should work for 95% of use cases. There could be a bean class annotated with an interceptor binding which is ignored (no associated interceptor enabled) but it shouldn't hurt to open such classes.

[geoand]

@mkouba Thanks!

[geoand]

I opened an initial PR: https://github.com/JetBrains/kotlin/pull/2163

[geoand]

We will need to update the kotlin compiler dependency to 1.3.40 once it is released (currently in EAP) to pick up the necessary changes

[geoand]

So it looks like there was extra work that needed to be done: https://github.com/JetBrains/kotlin/pull/2421

[Dufgui]

@geoand it's seems they forget your PR. :(

[geoand]

Indeed... If you would like to also ping on the Kotlin GitHub to show that is has some activity, that would be great!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you!
We are doing this automatically to ensure out-of-date issues does not stay around indefinitely.
If you believe this issue is still relevant please put a comment on it on why and if it truly needs to stay request or add 'pinned' label.

[maxandersen]

If someone want to pick this up then :

1) find all places we pass manually compiler options in our pom's like all-open:annotation=javax.ws.rs.Path and remove them.

2) see tests fail - especially this one

3) research how to make a kotlin compiler plugin

4) implement and enable kotlin compiler plugin

5) enable it and see the tests now pass.

Success!

[RotBolt]

Baiscally this compiler would be extension which would provide preconfigured open classes for these annoataions @ApplicationScoped, @RequestScoped. This is what AFAIU

[geoand]

Well basically for the annotations we already configure when we generate a Kotlin project.
Other than that, yes you have the correct idea

[RotBolt]

Well basically for the annotations we already configure when we generate a Kotlin project

by adding annoations in all-open plugin ? in the generated project

[geoand]

Exactly.

You can see the ones we add in the pom.xml "template" of the generated Kotlin projects

[RotBolt]

@geoand according to @mkouba comment we should open the classes which are annotated with with these annotations like @ApplicationScoped, @RequestScoped, I didn't understand other functions which this compiler plugin has to perform. If we can directly add these annoations in all-open plugin

[geoand]

@KaenDagger the idea is to have our own compiler plugin so that we don't have to configure the all-open plugin for every Quarkus application using Kotlin.
If we had the plugin, all we would do is configure that plugin and everything would be taken care of.

It makes things easier in the following ways:

• Less configuration in pom.xml (or build.gradle)
• By having a plugin we can update it in the future with whatever else we might need
• Dev mode setup becomes easier (in the Quarkus code), since you don't have to pass of ton of configuration options around (we have this working for Maven, but not Gradle but if we didn't have to do it all it would be great), we would just pass the the name of the plugin to the Kotlin compiler.

Does that make sense?

[RotBolt]

I get it now. I myself added some options to configure. Developer of the project has to manage those options themselves. By making the compiler plugin we would make that work easy for that developer of the project.
I get it now. thanks

[geoand]

Exactly :+1:

[RotBolt]

i have gone through the spring wrapper of all-open

In the maven version. They have added this KotlinSpringMavenExtension

For gradle they created SpringGradleSubPlugin

And for the list of supported presets , they have added in AllOpenCommandLineProcessor, two annotations have already been added to presets by @geoand

As far as I see. for quarkus-kotlin plugin we have to add support in kotlin

[geoand]

Yes that's what we tried to do and the Kotlin team prefered to go a different route... See https://github.com/JetBrains/kotlin/pull/2421

Which is why we need to create our own compiler plugin

[RotBolt]

I see. I will contact yanex for more info

On Fri, 3 Jan, 2020, 3:30 PM Georgios Andrianakis, [e-mail]
wrote:

Yes that's what we tried to do and the Kotlin team prefered to go a
different route... See JetBrains/kotlin#2421
https://github.com/JetBrains/kotlin/pull/2421

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/quarkusio/quarkus/issues/1157?email_source=notifications&email_token=AF5B53CDXOSEGV2HRBG5VC3Q34EDTA5CNFSM4G3MAID2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIAYH5Q#issuecomment-570524662,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AF5B53A6U3ABUOJA2ZRG3VLQ34EDTANCNFSM4G3MAIDQ
.

[geoand]

I'm closing this since @KaenDagger worked on it and encountered Kotlin issues and since we have since decided to go another route.