Locking build script dependencies locks some Kotlin jars at different versions

Gradle 7.0 uses Kotlin 1.4.31.

I want to use the newer Kotlin 1.4.32 to compile my code.

I included the following in my build.gradle.kts:

buildscript {
	configurations.configureEach {
		resolutionStrategy.activateDependencyLocking()
	}
}

plugins {
	kotlin("jvm") version "1.4.32"
}

./gradlew dependencies --write-locks generates a buildscript-gradle.lockfile whose contents are included below. This locks most Kotlin jars at 1.4.32, but 3 of them at 1.4.31. Why aren’t all the build script Kotlin jars locked at 1.4.31, as that’s what Gradle 7.0 uses? Shouldn’t Kotlin jars only be locked at 1.4.32 in the gradle.lockfile, not in the buildscript-gradle.lockfile?

# This is a Gradle generated file for dependency locking.
# Manual edits can break the build and are not advised.
# This file is expected to be part of source control.
com.github.gundy:semver4j:0.16.4=classpath
com.google.code.gson:gson:2.8.6=classpath
de.undercouch:gradle-download-task:4.0.2=classpath
org.antlr:antlr4-runtime:4.5.2-1=classpath
org.jetbrains.intellij.deps:trove4j:1.0.20181211=classpath
org.jetbrains.kotlin.jvm:org.jetbrains.kotlin.jvm.gradle.plugin:1.4.32=classpath
org.jetbrains.kotlin:kotlin-android-extensions:1.4.32=classpath
org.jetbrains.kotlin:kotlin-annotation-processing-gradle:1.4.32=classpath
org.jetbrains.kotlin:kotlin-build-common:1.4.32=classpath
org.jetbrains.kotlin:kotlin-compiler-embeddable:1.4.32=classpath
org.jetbrains.kotlin:kotlin-compiler-runner:1.4.32=classpath
org.jetbrains.kotlin:kotlin-daemon-client:1.4.32=classpath
org.jetbrains.kotlin:kotlin-daemon-embeddable:1.4.32=classpath
org.jetbrains.kotlin:kotlin-gradle-plugin-api:1.4.32=classpath
org.jetbrains.kotlin:kotlin-gradle-plugin-model:1.4.32=classpath
org.jetbrains.kotlin:kotlin-gradle-plugin:1.4.32=classpath
org.jetbrains.kotlin:kotlin-reflect:1.4.31=classpath
org.jetbrains.kotlin:kotlin-script-runtime:1.4.32=classpath
org.jetbrains.kotlin:kotlin-scripting-common:1.4.32=classpath
org.jetbrains.kotlin:kotlin-scripting-compiler-embeddable:1.4.32=classpath
org.jetbrains.kotlin:kotlin-scripting-compiler-impl-embeddable:1.4.32=classpath
org.jetbrains.kotlin:kotlin-scripting-jvm:1.4.32=classpath
org.jetbrains.kotlin:kotlin-stdlib-common:1.4.31=classpath
org.jetbrains.kotlin:kotlin-stdlib:1.4.31=classpath
org.jetbrains.kotlin:kotlin-util-io:1.4.32=classpath
org.jetbrains.kotlin:kotlin-util-klib:1.4.32=classpath
org.jetbrains.kotlinx:kotlinx-coroutines-core:1.3.8=classpath
org.jetbrains:annotations:13.0=classpath
empty=

You are applying the Kotlin plugin. This means the plugin and its dependencies are added to the buildscript class path. And the Kotlin Gradle plugin of course is written in Kotlin. Unfortunately this also leads to other problems, like when applying Kotlin 1.4 plugin in a Gradle version that ships with 1.3.

1 Like

Is there any way for Gradle to lock all Kotlin buildscript dependencies to the version it requires, and just inform plug-in writers that, to be compatible with Gradle version G, their plugins must be compatible with Kotlin version K?

The plugins should defer their Kotlin dependency versions to Gradle.

The same should be done for all builtin Gradle buildscript dependencies.

That seems much safer than the current situation.

Is there an existing GitHub issue for this?

Actually the same is true for Java or Groovy code.
If you write a plugin in Groovy 3 and try to use on Gradle that bundles Groovy 2 you might have problems.
Or if you compile a plugin in Java for Java 11 and then try to run a Gradle build that is using it with Java 8, you also have a problem.
Not sure about the Groovy case, but for the Java case it will end up with unknown class version error, for Kotlin it will warn you about incompatible versions on the class path afair.

I doubt there is much more that Gradle could sensibly do, but I agree that the plugins should use the minium version of the dependencies they need to support the oldest Gradle version they want to support and maybe not have a direct dependency on them.

For the Kotlin Gradle plugin there is for example https://youtrack.jetbrains.com/issue/KT-41142.

Actually from a compatibility point of view it would probably be the best idea to use Java and there the version that is the minimum verison for the oldest Gradle version you want to support for developing plugins. But from a development convenience point of view this is of course not the optimal solution.

No idea whether there is a Gradle issues about this topic.

1 Like