https://kotlinlang.org logo
Join Slack
Powered by
Hi folks. I'm having an issue upgrading the Micron...
# gradle
m
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?
t
Please open a Kotlin issue with a repro. Hard to say what could be wrong here
m
I cannot easily build a repro, this is a quite involved plugin. Or I could point you at a breaking PR if it helps.
t
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
m
I tested with 1.9.0, 1.9.10 and 1.9.20, it starts breaking with 1.9.20
🤔 1
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
t
hmm, yes - for all 
Kapt
tasks
that is strange. Is Micronaut Gradle plugin closed sourced?
m
no it's OSS
t
I will try to look into it tomorrow
👍 1
m
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
👍 1
by changing the Kotlin version in 
libs.versions.toml
to 1.9.10 it passes
I'll investigate more but I lack knowledge of how the Kotlin plugins set things up
Back to debugging. I'm reaching this:
No annotation processors provided. Skip KAPT processing.
So now have to figure out why...
t
aha, one sec - will find related commit
m
This is fishy. After I added this configuration block, I'm getting further:
Copy code
configurations.all {
               if (name.contains("kapt") && name.contains("Classpath") && name.contains("Custom")) {
                  println(name)
                  incoming.beforeResolve {
                      extendsFrom(configurations["kaptCustom"])
                  }
               }
            }
but still failing...
t
Please check this commit
though it is somewhat opposite to empty AP
m
Yeah, seems to be the opposite of what I'm seeing 🤔
oh wait seems this commit is not in 1.9.20
🤔 1
t
right 🤦‍♂️ It should be only in 2.0.0-Beta1
m
but then it means that may be the problem I'm seeing
let me see if I manually add dependencies from parent configurations before resolving...
t
though the issue it tries to fix is quite old one 🤔
m
Copy code
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 😮‍💨
t
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.
m
mmm that would be strange since it works perfectly fine for the main source set
t
ah, my bad - my comment above is incorrect. Was looking into wrong place.
m
I suspect it's related to stubs not being generated in this case
t
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?
m
it does configure it too
t
Basically kapt task exists on this condition. For main source set 
kaptClasspath
is not empty, but for custom one - it is empty
m
I see my code being called for 
kaptCustom
🤔 1
so yes, something has changed around this. That's why I had to add the dirty trick to reintroduce the 
extendsFrom
but even when I do so, it doesn't work and doesn't generate stubs
t
extendsFrom
is ignored for kapt configurations in 1.9.20
the fix I've posted above fixes it
m
mmm, how is one supposed to add dependencies then?
The code I added in the test:
Copy code
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.
So I'm wondering if I need a similar trick for stubs generation
this is basically a blocker for Micronaut 4.2 release, which supports Java 21
so if I can workaround, even with a temporary hack, that's better than nothing
yeah I think it's the same issue, when the task is invoked the kapt classpath is empty
now have to figure out what configuration it's using
So this is 
kaptClasspath
for the 
kaptGenerateStubsCustomKotlin
task
if you compare it with the "default" kapt generate stubs task
for some reason the custom one seems unconfigured
t
is it possible to run the test with Gradle 8.1?
m
trying...
also fails
t
From what I see on this line for 
kaptCustom
configuration kapt subplugin does not see any declared dependencies
m
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.
t
aha - and it is being called after script evaluation and before `afterEvaluate`s
m
doesn't explain why the stubs task isn't configured with a configuration tho
t
so this is the cause
it could affect stub as well
is it possible to add dependency without using 
afterEvaluate
?
m
no, because it's an extension which is configured by the user, so we can't tell what's going to be added
basically we're looking at the source sets that the user has declares as "additional source sets to process"
t
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
m
I will see if I can configure eagerly instead, it's a breaking change, but might be acceptable...
t
Hi, the fix should be available in the 1.9.21 release - now kapt task should receive dependencies added in 
afterEvaluate
👍 1
7 Views
Open in Slack
PreviousNext
Powered by