Am I correct in my understanding that because `kot...

# gradle

[Shannon Lloyd]

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?

[octylFractal]

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

[pniederw]

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

[octylFractal]

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

[pniederw]

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?

[octylFractal]

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

[pniederw]

Why would I want the 1.4 plugin for buildSrc?

[octylFractal]

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

[pniederw]

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.

[octylFractal]

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

[octylFractal]

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

[pniederw]

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

[Shannon Lloyd]

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.

[pniederw]

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

[pniederw]

buildSrc is effectively its own build

[octylFractal]

the runtimeClasspath of buildSrc is actually added to the main build 🙂

[pniederw]

that can't be true

[octylFractal]

mhm, I rely on that fact

[pniederw]

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

[Shannon Lloyd]

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.

[octylFractal]

now, the buildSrc's build.gradle(.kts) classpath is yet another entry

[octylFractal]

correct, it doesn't cause issues in application code (afaik), but it causes issues in the build

[pniederw]

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

[Shannon Lloyd]

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.

[Shannon Lloyd]

I believe it was application code.

[pniederw]

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.

[pniederw]

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

[pniederw]

that sounds pretty bad

[pniederw]

is there an issue for this?

[octylFractal]

ah, found my hack -- compileOnly(kotlin("gradle-plugin")) in buildSrc 😛

[octylFractal]

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)

[Shannon Lloyd]

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

[pniederw]

this kind of coupling is deadly

[octylFractal]

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

[Shannon Lloyd]

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

[pniederw]

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

[octylFractal]

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

[octylFractal]

the serialization plugin 1.4 can be used outside of buildSrc just fine

[pniederw]

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.

[pniederw]

because my main build will apply kotlin-conventions

[octylFractal]

and I'm pretty sure you can

[pniederw]

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

[pniederw]

I'm not sure it works though, at least not without your compileOnly trick.

[octylFractal]

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

[pniederw]

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

[jannis]

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.

[jannis]

Also getting some weird NoSuchMethodErrors when using kapt

[pniederw]

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.