This warning could be substantially more useful (upgrading to 2.1.0 from 2.0.10): ```1. > Configu...

# gradle

[Rob Elliot]

This warning could be substantially more useful (upgrading to 2.1.0 from 2.0.10):

1. > Configure project :
w: The artifact `org.jetbrains.kotlin:kotlin-compiler-embeddable` is present in the build classpath along Kotlin Gradle plugin.
This may lead to unpredictable and inconsistent behavior.
For more details, see: <https://kotl.in/gradle/internal-compiler-symbols>

I've read the section of the page, looked at my build.gradle and am none the wiser what it is I am meant to do. I'm not writing a gradle plugin and I don't think my build logic relies on any compiler symbols.

Turns out it was the kotlinter plugin, but I had to resort to disabling plugins and reenabling them one by one to work it out.

[Vampire]

Doesn't buildEnvironment task or a build --scan give the information you need to find where it comes from?

[Rob Elliot]

I didn't know about buildEnvironment. --scan would be inappropriate on this project.

As buildEnvironment can pinpoint what brought in the dependency, why can't the warning specify it? And why can't the page the warning sends you to tell you about buildEnvironment and the possibility that plugins are the problem?

[mbonnin]

> why can't the warning specify it?
The warning is probably emitted by the Kotlin compiler, which at this point doesn't know what was put in the global buildscript classpath

[Rob Elliot]

Fair point

[mbonnin]

This raises the question of why the Kotlin compiler would run in the global buildscript classpath though. I would expect it to be somewhat isolated, at least through the Kotlin compiler daemon

[mbonnin]

So maybe the warning comes from some other completely unrelated place 🤷

[mbonnin]

why can't the page the warning sends you to tell you about buildEnvironment and the possibility that plugins are the problem?

That'd be cool 👍

[Vampire]

As the message is using a Gradle dependency syntax and talks about the KGP, I acutally guess the message is not coming from the Kotlin Compiler, but indeed from the KGP.

That it does not provide where it is coming from might be because it cannot determine that, or JetBrains folks just don't know how to do it. 🤷‍♂️

That neither the message nor the link give hints about buildEnvironment and plugins might just be missing, maybe the JetBrains folks also were not aware of it.
Actually, depending on where the plugin is coming from, buildEnvironment also might not be able to provide the necessary information, for example if the plugin comes in from a buildSrc dependency, or from the settings plugin classpath iirc.

Maybe @tapchicoma can shed some light or take the feedback to maybe include those hints somewhere. 🙂

[mbonnin]

True, `buildEnvironment` can be misleading

[Alexander.Likhachev]

Thanks for raising the topic. This warning is reported by KGP and KGP indeed cannot determine what exactly brought the dependency as it occurs on the level of plugin dependencies resolution or even as it was mentioned above, can be brought via class loaders hierarchy from buildSrc. However, we are going to introduce a separate page describing how to deal with this problem when you’re not a plugin author. The link https://kotl.in/gradle/internal-compiler-symbols will be repointed then to this new page

[Alexander.Likhachev]

In general, the problem we are trying to solve with this is that kotlin compiler has a lot of API that has no stability guarantees. Then assume you have 2 plugins depending on different versions of kotlin compiler in a straightforward way. If they’re both applied in the same project, one of the dependencies would be bumped and most probably the related plugin is broken

[mbonnin]

Is the plan that KGP itself migrates to workers + classloader isolation?

[Alexander.Likhachev]

KGP is mostly migrated to using compiler in an completely isolated way, but there are some still leftovers for compatibility reasons with different components. We are going to get rid of them soon

[mbonnin]

TBH, I would put that warning for almost any transitive dependency in a Gradle build. I've had so many issues with antlr, okio, asm, etc... I just stopped counting

[Vampire]

Just change the conflict resolution strategy to fail then 🙂

[mbonnin]

Ahahahahahahahahahahahaha

[Vampire]

Why are you laughing, that's what you asked for, isn't it?

[mbonnin]

It was a nervous laugh, sorry 😅

[Vampire]

Well, you asked for warning, not failure

[Vampire]

Ah, ok 🙂

[mbonnin]

Yea, getting all the plugins to agree on their transitive dependencies is mission impossible

[mbonnin]

My point is that it's nice for KGP to display this warning but in today's state, I expect most build authors to have tripped into a classloader issue and be somewhat aware of those and it initially confused me because it looked like something KGP specific while it's generally a much more general issue about classloaders

[mbonnin]

Aren't there 2 issues actually?
• conflicting transitive dependencies (what the warning is about)
• using internal APIs (what the <https://kotl.in/gradle/internal-compiler-symbols|internal-compiler-symbols> page is about)

[mbonnin]

If KGP moves all compiler APIs usage to a different classloader, kotlinter can happily continue adding kotlin-compiler-embeddable to the global buildscript classpath

[mbonnin]

(not that it makes it a good citizen but it's the same for 90% of plugins out there)