Hi folks. I'm having an issue upgrading the Micronaut Gradle plugins to Kotlin 1.9.20. I have a coup...

# gradle

[melix]

Hi folks. I'm having an issue upgrading the Micronaut Gradle plugins to Kotlin 1.9.20. I have a couple tests failing when using kapt+a custom source set. It seems that the annotation processors are not called anymore in 1.9.20 on these custom source sets. Does that ring a bell to anyone?

[tapchicoma]

Please open a Kotlin issue with a repro. Hard to say what could be wrong here

[melix]

I cannot easily build a repro, this is a quite involved plugin. Or I could point you at a breaking PR if it helps.

[tapchicoma]

afaik there were no significant changes on the Kapt/Gradle side between 1.9.10 and 1.9.20 releases. In 1.9.0 release kapt tasks were decoupled from related KotlinJvmCompile tasks meaning if you are doing some additional configuration on KotlinJvmCompile task - you either also need to repeat it for KaptGenerateStubs task or use more generic approach

[melix]

I tested with 1.9.0, 1.9.10 and 1.9.20, it starts breaking with 1.9.20

[melix]

when using kapt.verbose=true I'm supposed to see debug info for all kapt tasks, right? Currently I see it only for kaptKotlin, but not for the kaptCustomKotlin task

[tapchicoma]

hmm, yes - for all Kapt tasks

[tapchicoma]

that is strange. Is Micronaut Gradle plugin closed sourced?

[melix]

no it's OSS

[melix]

https://github.com/micronaut-projects/micronaut-gradle-plugin/pull/864

[tapchicoma]

I will try to look into it tomorrow

[melix]

you can run :functional-tests:test --tests "io.micronaut.gradle.kotlin.KotlinLibraryFunctionalTest.test custom sourceSet for micronaut-library and kotlin with kotlin DSL for #plugin" and see it fail

[melix]

by changing the Kotlin version in libs.versions.toml to 1.9.10 it passes

[melix]

I'll investigate more but I lack knowledge of how the Kotlin plugins set things up

[melix]

Back to debugging. I'm reaching this:

No annotation processors provided. Skip KAPT processing.

So now have to figure out why...

[tapchicoma]

aha, one sec - will find related commit

[melix]

This is fishy. After I added this configuration block, I'm getting further:

configurations.all {
               if (name.contains("kapt") && name.contains("Classpath") && name.contains("Custom")) {
                  println(name)
                  incoming.beforeResolve {
                      extendsFrom(configurations["kaptCustom"])
                  }
               }
            }

[melix]

but still failing...

[tapchicoma]

Please check this commit

[tapchicoma]

though it is somewhat opposite to empty AP

[melix]

Yeah, seems to be the opposite of what I'm seeing 🤔

[melix]

oh wait seems this commit is not in 1.9.20

[tapchicoma]

right 🤦‍♂️ It should be only in 2.0.0-Beta1

[melix]

but then it means that may be the problem I'm seeing

[melix]

let me see if I manually add dependencies from parent configurations before resolving...

[tapchicoma]

though the issue it tries to fix is quite old one 🤔

[melix]

configurations.all {
               var conf = this
               if (name == "kaptClasspath_kaptCustomKotlin") {
                  incoming.beforeResolve {
                      configurations["kaptCustom"].dependencies.forEach {
                        conf.dependencies.add(it)
                      }
                  }
               }
            }

gets me further but still nothing. And it looks like there are no stubs generated 😮‍💨

[tapchicoma]

The more I look into it - the more it looks like kapt compiler plugin issue itself and not related to Gradle/Kapt. And there was some significant refactoring to support K2.

Please open a new issue - you could just reference your branch as a repro.

[melix]

mmm that would be strange since it works perfectly fine for the main source set

[tapchicoma]

ah, my bad - my comment above is incorrect. Was looking into wrong place.

[melix]

I suspect it's related to stubs not being generated in this case

[tapchicoma]

I see that your plugin tries to configure Kapt standard configurations like "kapt", "kaptTest", but not for custom source set - "kaptCustom". Is it intended behaviour?

[melix]

it does configure it too

[melix]

this is done in an afterEvaluate and calls https://github.com/micronaut-projects/micronaut-gradle-plugin/blob/252e198ce392b51[…]n/src/main/java/io/micronaut/gradle/MicronautKotlinSupport.java

[melix]

more specifically here -> https://github.com/micronaut-projects/micronaut-gradle-plugin/blob/252e198ce392b51[…]n/src/main/java/io/micronaut/gradle/MicronautKotlinSupport.java

[tapchicoma]

Basically kapt task exists on this condition. For main source set kaptClasspath is not empty, but for custom one - it is empty

[melix]

I see my code being called for kaptCustom

[melix]

so yes, something has changed around this. That's why I had to add the dirty trick to reintroduce the extendsFrom

[melix]

but even when I do so, it doesn't work and doesn't generate stubs

[tapchicoma]

extendsFrom is ignored for kapt configurations in 1.9.20

[tapchicoma]

the fix I've posted above fixes it

[melix]

mmm, how is one supposed to add dependencies then?

[melix]

The code I added in the test:

configurations.all {
               var conf = this
               if (name == "kaptClasspath_kaptCustomKotlin") {
                  incoming.beforeResolve {
                      configurations["kaptCustom"].dependencies.forEach {
                        conf.dependencies.add(it)
                      }
                  }
               }
            }

works around the fact that extendsFrom is ignored (uh, silly). Yet, now I see the kapt task being invoked, but it doesn't work since it says all sources are up-to-date, which I think comes from the fact no stubs are generated.

[melix]

So I'm wondering if I need a similar trick for stubs generation

[melix]

this is basically a blocker for Micronaut 4.2 release, which supports Java 21

[melix]

so if I can workaround, even with a temporary hack, that's better than nothing

[melix]

yeah I think it's the same issue, when the task is invoked the kapt classpath is empty

[melix]

now have to figure out what configuration it's using

[melix]

So this is kaptClasspath for the kaptGenerateStubsCustomKotlin task

[melix]

if you compare it with the "default" kapt generate stubs task

[melix]

for some reason the custom one seems unconfigured

[tapchicoma]

is it possible to run the test with Gradle 8.1?

[melix]

trying...

[melix]

also fails

[tapchicoma]

From what I see on this line for kaptCustom configuration kapt subplugin does not see any declared dependencies

[melix]

the dependencies are added in an afterEvaluate (see link above). However from what I've seen, they are still added before this code is executed.

[tapchicoma]

aha - and it is being called after script evaluation and before `afterEvaluate`s

[melix]

doesn't explain why the stubs task isn't configured with a configuration tho

[tapchicoma]

so this is the cause

[tapchicoma]

it could affect stub as well

[tapchicoma]

is it possible to add dependency without using afterEvaluate?

[melix]

no, because it's an extension which is configured by the user, so we can't tell what's going to be added

[melix]

basically we're looking at the source sets that the user has declares as "additional source sets to process"

[tapchicoma]

I could not come up with any workaround except dropping usage of afterEvaluate kodee sad

And I advice you to create an issue - possibly we could fix it in 1.9.21 release

[melix]

I will see if I can configure eagerly instead, it's a breaking change, but might be acceptable...

[melix]

@tapchicoma https://youtrack.jetbrains.com/issue/KT-63366/Kapt-processing-fails-with-custom-source-sets

[tapchicoma]

Hi, the fix should be available in the 1.9.21 release - now kapt task should receive dependencies added in afterEvaluate