Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

resolution failure when dependency locks and kotlin-dsl plugin are present #10697

rpalcolea opened this issue Sep 12, 2019 · 4 comments


Copy link

@rpalcolea rpalcolea commented Sep 12, 2019

Given the following build file:

plugins {

dependencyLocking {

repositories {

java {
    targetCompatibility = JavaVersion.VERSION_1_8
    sourceCompatibility = JavaVersion.VERSION_1_8

when running ./gradlew dependencies --write-locks, the compileClasspath configuration has the following:

compileClasspath - Compile classpath for compilation 'main' (target  (jvm)).
Persisted dependency lock state for configuration ':compileClasspath'
+--- org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.3.41
|    \--- org.jetbrains.kotlin:kotlin-stdlib-jdk7:1.3.41
|         \--- org.jetbrains.kotlin:kotlin-stdlib:1.3.41
|              \--- org.jetbrains:annotations:13.0
\--- org.jetbrains.kotlin:kotlin-reflect:1.3.41
     \--- org.jetbrains.kotlin:kotlin-stdlib:1.3.41 (*)

This results in this lock file:

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

This looks fine, however when running ./gradlew build, compileKotlin fails with the following:

Execution failed for task ':compileKotlin'.
> Could not resolve all files for configuration ':compileClasspath'.
   > Resolved 'org.jetbrains.kotlin:kotlin-stdlib-common:1.3.41' which is not part of the dependency lock state

Running ./gradlew dependencies this time will show a different graph:

compileClasspath - Compile classpath for compilation 'main' (target  (jvm)).
+--- org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.3.41
|    +--- org.jetbrains.kotlin:kotlin-stdlib:1.3.41
|    |    +--- org.jetbrains.kotlin:kotlin-stdlib-common:1.3.41
|    |    \--- org.jetbrains:annotations:13.0
|    \--- org.jetbrains.kotlin:kotlin-stdlib-jdk7:1.3.41
|         \--- org.jetbrains.kotlin:kotlin-stdlib:1.3.41 (*)
+--- org.jetbrains.kotlin:kotlin-reflect:1.3.41
|    \--- org.jetbrains.kotlin:kotlin-stdlib:1.3.41 (*)
+--- org.jetbrains.kotlin:kotlin-reflect:{strictly 1.3.41} -> 1.3.41 (c)
+--- org.jetbrains.kotlin:kotlin-stdlib-jdk8:{strictly 1.3.41} -> 1.3.41 (c)
+--- org.jetbrains.kotlin:kotlin-stdlib:{strictly 1.3.41} -> 1.3.41 (c)
+--- org.jetbrains.kotlin:kotlin-stdlib-jdk7:{strictly 1.3.41} -> 1.3.41 (c)
+--- org.jetbrains:annotations:{strictly 13.0} -> 13.0 (c)
\--- org.jetbrains.kotlin:kotlin-stdlib-common:1.3.41 FAILED

kotlin-stdlib-common was introduced during compilation.

The current workaround is to add the dependency manually to the lock files org.jetbrains.kotlin:kotlin-stdlib-common:<version>.

Wondering if this is related to: and

Copy link

@ljacomet ljacomet commented Sep 12, 2019

So this is caused by the tricks pulled by kotlin-dsl to reduce download of Kotlin dependencies.
But the dependency graph is trimmed, which does not cause issue as all the classes are available through the Gradle distribution itself.
However, when locking constraints show up, they end up "completing" the graph, which causes the missed dependency to be included and thus changing the resolution state.

The current workaround is to add the missing dependency to the lock file by hand.

A proper fix for Gradle 6.0 will be done: drop that embedded repository concept altogether.
A smaller fix will most likely be included if a Gradle 5.6.3 is planned, see #10691

Copy link

@ljacomet ljacomet commented Sep 17, 2019

Issue for 6.0 fix: #10745

Copy link
Contributor Author

@rpalcolea rpalcolea commented Sep 17, 2019

awesome! thanks for the quick fix @ljacomet

@jjohannes jjohannes added this to the 5.6.3 milestone Oct 11, 2019
ljacomet added a commit that referenced this issue Oct 11, 2019
* kotlin-stdlib now depends on kotlin-stdlib-common, this was not
reflected in the setup of the embedded kotlin repo.
* A way to experience this issue was with locking on a kotlin-dsl

Fixes #10697
Copy link

@eskatos eskatos commented Oct 12, 2019

Fixed for Gradle 5.6.3 in #10691

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

4 participants