https://kotlinlang.org logo
Join Slack
Powered by
Hello, we're testing Gradle 9-RC1 internally where...
# gradle
h
Hello, we're testing Gradle 9-RC1 internally where we're still on 
2.0.21
(don't ask) which is failing with
Copy code
java.lang.NoSuchMethodError: 'org.gradle.api.provider.Provider org.gradle.api.provider.Provider.forUseAtConfigurationTime()'
	at org.jetbrains.kotlin.gradle.plugin.internal.ConfigurationTimePropertiesAccessorG6.usedAtConfigurationTime(ConfigurationTimePropertiesAccessorG6.kt:19)
	at org.jetbrains.kotlin.gradle.plugin.internal.ConfigurationTimePropertiesAccessorKt.usedAtConfigurationTime(ConfigurationTimePropertiesAccessor.kt:49)
	at org.jetbrains.kotlin.gradle.utils.FileUtilsKt.getLocalProperties(fileUtils.kt:145)
	at org.jetbrains.kotlin.gradle.internal.properties.PropertiesBuildService$Companion$registerIfAbsent$1.execute(PropertiesBuildService.kt:168)
	at org.jetbrains.kotlin.gradle.internal.properties.PropertiesBuildService$Companion$registerIfAbsent$1.execute(PropertiesBuildService.kt:167)
Just want to confirm - is this a failure you'd expect in the 
gradle85
variant?
Understood - we have a barebones test that is not giving the required metadata to the Kotlin Gradle Plugin to understand that it should use the 
gradle85
variant. By manually removing 
main
it works
Although, could it be that the metadata for 9 is so different that the Gradle plugin opts to go for 
main
instead of 
gradle85
, and that's what's causing us the issue?
t
2.0.21
is not compatible with Gradle 9
2.1.21
should work in most cases
h
Managed to make it work 🙂
(just running a sample project with little to no code)
the issue is we use 
GradleRunner
and we weren't specifying what version of Gradle it is running, so the Kotlin Gradle Plugin was defaulting to 
main
but yeah, we're definitively not launching this until I get 2.1.21+ as the only version of Kotlin inside the company. Biggest issue is that you dropped support for Kotlin 1.4 targetCompatibility. You can imagine how this is a problem 💀
t
h
I assume the removal of the 
KOTLIN_1_4
happened just on the gradle plugin, the idea here is that for whatever packages I need that compatibility, I could set it to 2.0.21 and it'd just work?
t
yes, and pass 
-language-version 1.4
via 
freeCompilerArgs
though there are caveats regarding compiler plugins - there are not supported well in such a case
h
Anyway, the heavy lift it would be on our side to allow more than one 2.x package would kill us (we have a custom dependency management setup that's almost older than me), I prefer to force the teams to just upgrade to Kotlin 2.x
but this is certainly a very good feature, wish I could use it!
t
I assume the removal of the 
KOTLIN_1_4
happened just on the gradle plugin
Also we are working on restoring some DSL support for old values that could be used with older Kotlin compiler versions
🙌 1
h
Ok, this did seem a little too good to be true - 
GradleRunner
, with a particular Gradle version, will attempt to download it, so it works well locally, but not remotely where it is network jailed. Yahor, there is no way for me to specify the Gradle variant right? By default, it can't find an optimal one, it defaults to 
main
😕. Would it be possible to change it from 
main
to whatever is the latest one?
According to this (let's imagine it's the 2.0.21 where gradle85 likely said what 813 says here), should 9.0.0 use gradle85?
t
gradle8.13
should be used with Gradle 9.0. You could provide directly to the test https://repo1.maven.org/maven2/org/jetbrains/kotlin/kotlin-gradle-plugin/2.2.0/kotlin-gradle-plugin-2.2.0-gradle813.jar via 
GradleRunner.withPluginClasspath
BTW why are you stuck on older Kotlin versions?
h
We initially allowed people to select whatever version of Kotlin they wanted. This has now translated into some core libraries using Kotlin 1.3/compiling with 
--languageVersion 1.4
, and an untold amount of customers that also use it. If we elevate the number, a lot of these packages will need to be fixed. It's hard to get these things done at such a scale. You do not want to know how difficult it was (still ongoing) to get people off JDK8.
thank you color 1
t
It's hard to get these things done at such a scale
In theory you could try to look into OpenRewrite rules such mass migration 🤔
h
Yeah, we have an internal tool that uses GenAI + OpenRewrite recipes, but it's just way too many teams spread all over the world, a lot of red tape to force people to use it. For Kotlin 2.x, we're trying to keep everyone on the same version across the company, but as you've seen, we haven't been able to move past 2.0 because of the higher target compatibility in 2.1 + the Gradle 7 incompatibility (which I hope to address, I already migrated a few central ones myself)
👍 1
Open in Slack
Previous
Powered by