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 'com.google.guava:guava-parent:32.1.2-jre' which is part of the dependency lock state
BUILD FAILED in 1s
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:
working.txt is where the build (…/gradlew assemble) is passing. “com.google.guava:guava:11.0.2” is fetching guava-parent.
issue.txt is where the build (…/gradlew assemble) is failing with the aforementioned error. The same version of the library “com.google.guava:guava:11.0.2” isn’t fetching guava-parent.
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?
Workaround
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: 11.0.16.1 (Amazon.com Inc. 11.0.16.1+9-LTS)
OS: Windows 11 10.0 amd64
Nice!
I deleted C:\Users\myUserName\.m2\repository\com\google\guava and also removed lockMode = LockMode.LENIENT from gradle files. Now, the build is successful:
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.
