Build failing in local environment because of version locking

After the addition of gradle version locks in code repository by some other developer in my organization, now the build is failing in my machine:

/c/git/nextgenRepository/myProject (dev)
$ ../gradlew assemble
> Task :myProject:compileJava FAILED
:myProject:compileJava took 30ms
Task timings:

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':myProject:compileJava'.
> Could not resolve all files for configuration ':myProject:compileClasspath'.
   > Did not resolve '' which is part of the dependency lock state
23 actionable tasks: 1 executed, 22 up-to-date

When I compared dependencies of myProject from my machine (which has issue) and that from another developer’s machine (where it’s working fine), found the following difference:

  1. working.txt is where the build (…/gradlew assemble) is passing. “” is fetching guava-parent.
  2. issue.txt is where the build (…/gradlew assemble) is failing with the aforementioned error. The same version of the library “” isn’t fetching guava-parent.

When we check the dependencies on maven: : indeed, it doesn’t have dependencies on “guava-parent”. Details on maven site are consistent with the dependencies in my machine.

Dependencies listed in

Then how come it’s different in everyone else’s machine? It’s working fine in everyone else’s machine. Caching somewhere? How to resolve this issue in my machine?

Builds are failing in my local. As a workaround, I’ve disabled the version locking in my machine with the following statement in build.gradle:

lockMode = LockMode.LENIENT

My local environment

$ ./gradlew --version

Gradle 6.9.2

Build time:   2021-12-21 20:18:38 UTC
Revision:     5d94aa68c0fdbe443838bb977080e3b9f273e889

Kotlin:       1.4.20
Groovy:       2.5.12
Ant:          Apache Ant(TM) version 1.10.9 compiled on September 27 2020
JVM: ( Inc.
OS:           Windows 11 10.0 amd64

Prev post

Delete ~/.m2/repository/com/google/guava, then it will most probably work.
If it does so, I’ll happily explain why.

1 Like

I deleted C:\Users\myUserName\.m2\repository\com\google\guava and also removed lockMode = LockMode.LENIENT from gradle files. Now, the build is successful:

959 actionable tasks: 162 executed, 797 up-to-date

Explanation please…

Your main problem is, that you use mavenLocal() and most probably without repository content filter and as first repository.

mavenLocal() is broken by design by Maven already as it is not really a pure repository but a mixture of repository and download cache for Maven builds. In the cache case only the files downloaded by Maven are present and all other files like additional artifacts with classifier or Gradle Module Metadata are simply missing, and Gradle then sees this broken state that might not be discoverable as broken.

You can read more about mavenLocal() and its multitude of problems at Declaring repositories.

In your case you built in the past some Maven project that used guava and thus only had the POM available, but not the GMM. If you compare the POM and the GMM, you also see the difference that is also reflected in your screenshot.

The right side is coming from the POM where the dependencies are contained without version and the versions coming from the dependencyManagement in the parent POM, making it concrete version requests for Gradle.

The left side is coming from the GMM where the dependencies are also contained wihtout version. But there more correctly the parent pom is included as platform / BOM dependency then adding the version constraints for those dependencies.


This was a life saver - thanks so much @Vampire !!

1 Like