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?

correct, you can use 1.4 if you use the worker API and classpath isolation, but not in normal buildscript code

Stuck on 1.3.72 for what? Build script code or application code?

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

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?

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

Why would I want the 1.4 plugin for buildSrc?

so that it defaults your versions to 1.4 and has the appropriate compiler bound I think

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.

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

But then what's the problem with using different versions of Kotlin Gradle plugin for buildSrc code and application code.

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.

I don't understand. The build class path for buildSrc and main build should be totally separated.

the runtimeClasspath of

buildSrc

is actually added to the main build 🙂

that can't be true

mhm, I rely on that fact

it's added to build script class path of the main build, not the class path of your application code

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.

now, the buildSrc's

build.gradle(.kts)

classpath is yet another entry

Did you get a build failure compiling/running your build scripts. or a build failure compiling/running your application code?

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

.

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.

ah, found my hack --

compileOnly(kotlin("gradle-plugin"))

in

buildSrc

😛

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

this kind of coupling is deadly

I really don't think it's as tightly coupled as it seems, just requires some care

Also: https://github.com/gradle/gradle/issues/14211

at the very least, the solution needs to be clearly documented

.... 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.

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.

and I'm pretty sure you can

if that works, then this may just be a big misunderstanding.

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

right, but it's the runtime class path for build scripts (which also determines the kotlin plugin version), not for application code.

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.

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.