https://kotlinlang.org
Join Slack
Am I correct in my understanding that because `kotlin-dsl` in buildSrc bundles its own version of Ko...
# gradle
s
Am I correct in my understanding that because 
kotlin-dsl
in buildSrc bundles its own version of Kotlin (which I believe is currently 1.3.72), it is currently impossible to upgrade a Gradle kotlin project to 1.4.0 if we are also authoring plugins using 
kotlin-dsl
in buildSrc? We're seeing classpath issues (e.g. NoSuchMethodErrors) relating to still having 1.3.72 on the classpath after upgrading everything to 1.4.0 (we end up with both versions on the classpath). Are we basically stuck on 1.3.72 until Gradle releases a version with a bundled Kotlin 1.4.x?
👌 2
o
correct, you can use 1.4 if you use the worker API and classpath isolation, but not in normal buildscript code
p
Stuck on 1.3.72 for what? Build script code or application code?
o
build script code, though getting the gradle plugin to apply 1.4 when your 
buildSrc
is on 1.3.72 can be.... difficult, if I recall correctly
p
I assume 
buildSrc
uses whatever is bundled with Gradle, which as of 6.6 is 1.3.72. And you are saying it might be difficult to build my application code with 1.4?
o
well, if you don't depend on the Kotlin gradle plugin in your 
buildSrc
, it's no issue, otherwise you normally would want the 1.4 plugin and I think but could be wrong that it causes issues. Maybe that's a thing of the past
p
Why would I want the 1.4 plugin for buildSrc?
o
so that it defaults your versions to 1.4 and has the appropriate compiler bound I think
p
Oh you mean because precompiled script plugins can't define a plugin version but this must be done in buildSrc/build.gradle.kts? I think I'm starting to understand.
o
realistically it's been a long time since I had to tussle with mixing versions like this but I had one project with notes about it
no, I mean that the kotlin gradle plugin will allow you to write e.g. 
implementation(kotlin("stdlib-jdk8"))
and it defaults to the plugin's version
p
But then what's the problem with using different versions of Kotlin Gradle plugin for buildSrc code and application code.
s
The issue is that 
kotlin-dsl
is still pulling in 1.3.72 (until a new Gradle release upgrades it to 1.4.0), and even if I have explicitly specified 1.4.0 in my project, 1.3.72 remains on the build classpath, and the two versions conflict with each other during the build, resulting in things like NoSuchMethodErrors.
p
I don't understand. The build class path for buildSrc and main build should be totally separated.
buildSrc is effectively its own build
o
the runtimeClasspath of 
buildSrc
is actually added to the main build 🙂
p
that can't be true
o
mhm, I rely on that fact
p
it's added to build script class path of the main build, not the class path of your application code
s
I'm just explaining what we've seen. I don't know why it behaves this way. We upgraded our project to 1.4.0, and nothing in our deps was pulling in 1.3.72, but it remained on the classpath and caused the build to fail.
o
now, the buildSrc's 
build.gradle(.kts)
classpath is yet another entry
correct, it doesn't cause issues in application code (afaik), but it causes issues in the build
p
Did you get a build failure compiling/running your build scripts. or a build failure compiling/running your application code?
s
I don't think this is just me, btw. Others have reported that upgrading to 1.4.0 does not work if you are using buildSrc with 
kotlin-dsl
.
I believe it was application code.
p
If it's application code, then I think for some reason, 1.3.72 kotlin plugin/compiler is used to compile your application code, even though you have 1.4 stdlib on your application class path.
I think it's due to the limitation I mentioned: .kts files can't yet specify a plugin version, instead must add the plugin version to 
implementation
configuration of 
buildSrc/build.gradle.kts
, which probably means you can only use the same (1.3.72) plugin version in your main build scripts
that sounds pretty bad
is there an issue for this?
o
ah, found my hack -- 
compileOnly(kotlin("gradle-plugin"))
in 
buildSrc
😛
so it uses the native gradle-plugin to compile against, but allows the root project to specify the actual version (or you could just make an alternative 
runtimeOnly
entry)
s
No idea. I haven't seen one. 1.4 seems to be on people's radar for Gradle 7 though https://github.com/gradle/gradle/issues/12660 although it would be good to have this working asap if it blocks people from adopting Kotlin 1.4
p
this kind of coupling is deadly
o
I really don't think it's as tightly coupled as it seems, just requires some care
s
p
at the very least, the solution needs to be clearly documented
o
.... yea, that's not a real issue that should be fixed. 
buildSrc
is effectively a plugin operating in gradle-space, so it has to compile against gradle's internal kotlin 1.3.72, just like gradle plugins have to compile against java 8 for widespread use.
the serialization plugin 1.4 can be used outside of 
buildSrc
just fine
p
I don't see a problem with using 1.3.72 for buildSrc, It's just that in 
buildSrc/src/main/kotlin/kotlin-conventions.gradle.kts
, I want to apply the 1.4 plugin.
because my main build will apply 
kotlin-conventions
o
and I'm pretty sure you can
p
if that works, then this may just be a big misunderstanding.
I'm not sure it works though, at least not without your 
compileOnly
trick.
o
right, you do need that trick, I am a bit surprised that the behavior of using 
runtimeClasspath
isn't documented, but it also feels a little expected to me if you consider that `buildSrc`'s compiled code is added to the classpath, so must the runtime classpath
p
right, but it's the runtime class path for build scripts (which also determines the kotlin plugin version), not for application code.
j
I’m running into the same problem. Can’t make Kotlin 1.4 work. The 
compileOnly
trick doesn’t seem to work for me. I think because I actually use the Gradle Plugin, since I have a custom Plugin in the 
buildSrc
Folder.
Also getting some weird 
NoSuchMethodErrors
when using 
kapt
p
We've been running into the same problem with dokka-gradle-plugin, which depends on Kotlin 1.4. I think it's time for Gradle (or Kotlin) folks to clarify/document what works (and how) and what doesn't.
20 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by