Recompilation kotlin sources in dev mode should use compiler plugins

[jhorstmann]

Description Using quarkus 0.16.0 in a kotlin project, when hot reloading is triggered it seems like the kotlin files are recompiled without any kotlin compiler plugins. Consider a resource like the following

@Path("/greeting")
@ApplicationScoped
class GreetingResource @Inject constructor(val greetingService: GreetingService) { ... }

In order for this class to work correctly, it needs to not be final and to have a default constructor. Both can be achieved by configuring the maven kotlin-maven-plugin

<configuration>
    <compilerPlugins>
        <plugin>all-open</plugin>
        <plugin>no-arg</plugin>
    </compilerPlugins>
    <pluginOptions>
        <option>all-open:annotation=javax.enterprise.context.ApplicationScoped</option>
        <option>no-arg:annotation=javax.enterprise.context.ApplicationScoped</option>
    </pluginOptions>
</configuration>

And indeed the application is working when initially starting with

mvn compile quarkus:dev

But as soon as the source is modified the reload fails with

Caused by: javax.enterprise.inject.spi.DeploymentException: Found 2 deployment problems: 
[1] Normal scoped bean must not be final: CLASS bean [types=[GreetingResource, java.lang.Object], qualifiers=[@Default, @Any], target=GreetingResource]
[2] Normal scoped beans must declare a non-private constructor with no parameters: CLASS bean [types=[GreetingResource, java.lang.Object], qualifiers=[@Default, @Any], target=GreetingResource]

Implementation ideas Ideally the kotlin extension would reuse the configuration of the kotlin-maven-plugin from pom.xml. Alternatively there would need to be a separate configuration option for plugins of the quarkus-kotlin extension.

Issue #1157 is related, but this issue is actually more generic as there might be more classes or annotations that need special treatment by the kotlin compiler, which would then break after hot reloading.

[geoand]

@jhorstmann would you like to take a stab at it?

[jhorstmann]

@geoand I had a look into the code and can try to implement this. The rough idea would be

• In DevMojo.addProject, try to extract plugin configuration from the injected MavenProject or MavenSession. This requires that the mojo be invoked as part of the maven lifecycle. I don't think it would be easy to get this information from the LocalProject, as that only contains the raw maven model, not the effective configuration.
• Add compiler specific settings to DevModeContext.ModuleInfo. Also needs to resolve the classpath of any configured compiler plugins.
• Probably makes sense to also extract java compiler options as these also seem to be hardcoded in JavaCompilationProvider.
• Map this compiler configuration to CompilationProvider.Context in ClassLoaderCompiler.

What I do not like about this approach is that there would be some kotlin compiler specific code in the DevMojo, but at the moment I can't think of another way. Parsing the compiler configuration would also duplicate some code from the kotlin-maven-plugin.

[geoand]

Perhaps @aloubyansky would care to comment on the proposed approach?

[jhorstmann]

Maybe the above outline is much more complex than needed. For most cases it would probably be enough to configure the no-arg and all-open plugins for any scope annotations. This should even work with the NormalScope meta annotation. I'm not using jpa at the moment, but I guess the no-arg would also be needed for any jpa entitites.

[geoand]

That sounds like a reasonable first step and best avoid all the complexity if we can

[abreu-dev]

Sorry for asking, but is there some workaround until this is fixed?

[geoand]

Not yet unfortunately. There where some Java compiler related changes that went into dev mode recently which might make tackling this a lot easier if someone wants to give it a shot.

[stale[bot]]

This issue/pullrequest has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[heri333]

I'm still very interested in a fix.

[geoand]

6030 should hopefully take care of the issue

[geoand]

Reopening as we still need to address the Gradle part in #6035

[geoand]

We have since decided that we will most likely go down the road of not requiring any Kotlin compiler plugins, but instead have Quarkus apply the necessary transformations. This will make the Kotlin experience frictionless no what matter what the build tool.

[evanchooly]

related #9856

[emmanuelbernard]

An idea from @aloubyansky is that we could look at Gradle list of tasks and run the compile one (instead of compiling ourselves)

[evanchooly]

jotting down notes:

when the dev plugins are launched from the build tool, context could be gathered and passed in to the plugin which can (hopefully) generically apply that context upon each rebuild/reload. this change would apply to both maven and gradle builds.

[jamesward]

What is the status of this? I just ran into this as described in: https://github.com/quarkusio/quarkus/issues/4266

[geoand]

@glefloch wasn't this fixed?

[glefloch]

Not really, it drops from my TODO list. In the current behaviour, we collect java arguments from Maven / Gradle mojo/task, and we forward it to the devmode context. It is also possible to set custom compiler arguments by configuration the dev mojo/task. We cannot really do the same things with kotlin as we don't depend on the Maven/Gradle plugin. I think we could introduce a new property in the dev mojo/task to set kotlin specific compiler arguments, this would avoid mixing java and kotlin compiler arguments in the same list (which does not work). WDYT of this @geoand, @aloubyansky ?

[aloubyansky]

We could handle it in the same way we handle the Java compiler config. I.e. we could check whether the user has specified kotilinCompilerArgs and if not, check whether corresponding Kotlin compiler plugin was configured and if so pull it from there?

[StephenOTT]

I am coming from: https://github.com/quarkusio/quarkus/issues/3591. Does this ongoing issue mean that @Valid does not work with Kotlin + Quarkus?

[glefloch]

@StephenOTT you can configure custom kotlin compiler arguments directly in the quarkus devmode mojo/task as documented here: https://quarkus.io/guides/kotlin#configuring-live-reload-compiler

This issue is about automatically collecting kotlin compiler arguments from kotlin compile mojo/task and this avoid to declare them both in the kotlin plugin and in the quarkus plugin.

[mschorsch]

This issue is about automatically collecting kotlin compiler arguments from kotlin compile mojo/task and this avoid to declare them both in the kotlin plugin and in the quarkus plugin.

@glefloch Have you any idea when this will be fixed?

[mschorsch]

I've found a workaround for Gradle: https://github.com/quarkusio/quarkus/issues/37109#issuecomment-1828352002