Puzzled by a guice-5.0.1-no_aop runtimeClasspath issue

This small build.gradle file is a source of major headache…

plugins {
    id 'application'
}

repositories {
    mavenCentral()
}

dependencies {
    implementation 'io.github.cdancy:artifactory-rest:1.0.0'
    implementation 'org.codehaus.groovy:groovy-all:3.0.5'
}

Running: gradle clean build gives:

* What went wrong:
Execution failed for task ':startScripts'.
> Error while evaluating property 'relativeClasspath' of task ':startScripts'
   > Could not resolve all files for configuration ':runtimeClasspath'.
      > Could not find guice-5.0.1-no_aop.jar (com.google.inject:guice:5.0.1).
        Searched in the following locations:
            https://repo.maven.apache.org/maven2/com/google/inject/guice/5.0.1/guice-5.0.1-no_aop.jar

I can’t figure out where the problem comes from, but changing id 'application' to id 'java', or upgrading groovy to 3.0.6 or removing one of the dependencies makes the problem go away. I don’t want to make it go away, I want to understand. Can someone help me debug this mystery please?

Gradle 7.4.2
Groovy 3.0.9
Kotlin; 1.5.31
JVM 11.0.14 Adoptium 11.0.14+9

I wrote a pom.xml:

<dependencies>
  <dependency>
      <groupId>io.github.cdancy</groupId>
      <artifactId>artifactory-rest</artifactId>
      <version>1.0.0</version>
  </dependency>
  <dependency>
      <groupId>org.codehaus.groovy</groupId>
      <artifactId>groovy-all</artifactId>
      <version>3.0.5</version>
  </dependency>
</dependencies>

And I was able to find the following:

[INFO] \- org.codehaus.groovy:groovy-all:jar:3.0.5:compile
...
[INFO]    +- org.codehaus.groovy:groovy-testng:jar:3.0.5:compile
[INFO]    |  \- org.testng:testng:jar:7.1.0:runtime
[INFO]    |     +- com.beust:jcommander:jar:1.72:runtime
[INFO]    |     \- com.google.inject:guice:jar:no_aop:4.1.0:runtime   <<<< Here it is!!!!!

How can I discover the same thing using gradle?

I wrote this gist. It does the job. How could it be incorporated in gradle? Also it would be nice if gradle could also list the artifacts when it lists dependencies. In this case it’s the only way to find what’s wrong.

I am getting same issue, but unable to resolve it. I am not sure why this dependency is required, because I have not configured this dependency in buid.gradle. Please let me know if any pointers.

@Martin_d_Anjou I have updated as per your comment id ‘java’ also groovy 3.0.6 but still issue is not resolved.

> Task :compileJava FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':compileJava'.
> Could not resolve all files for configuration ':compileClasspath'.
   > Could not find guice-5.0.1-no_aop.jar (com.google.inject:guice:5.0.1).
     Searched in the following locations:
         https://repo1.maven.org/maven2/com/google/inject/guice/5.0.1/guice-5.0.1-no_aop.jar

I have checked the Repo this jar is not present from version 5. This jar is present in previous version like 4.x.x.

I have checked the Repo this jar is not present from version 5. This jar is present in previous version like 4.x.x.

Exactly, you already discovered the most important point.

If you now execute gw dependencies --configuration runtimeClasspath, you can can see that there are dependencies that depend on guice4 which are updated to depend on guice5 due to conflict resolution.

One of those dependencies defines it needs the jar with classifier no_aop, so you can go through those and search for the one with the classifier in the dependencies.
In the original example, this is org.testng:testng:7.1.0.

One solution could for example be to use a dependency constraint to upgrade the TestNG dependency to a version that depends on guice5 and thus does not have the bad classifier specified.

Another solution could be to not depend on groovy-all, but just on the modules you actually really need and then maybe do not need the whole groovy-testng module that depends on TestNG.

Another solution could be to update any other dependency up the chain, like the Groovy one.
In the original example using Groovy 3.0.6 fixes the problem.
In your case it seems there are more of these dependencies.

Another solution could be to use a component metadata rule to fix the metadata of the dependency that depends on the classifier to remove the classifier.

Unfortunately even a build --scan does not directly show the root of the problem, but needs the same reasoning and manual checking described above.
Maybe it would make sense that someone opens an issue on GitHub to improve the diagnostic message in such a case.

Thanks @Vampire for detailed reply. I am able to identify the dependencies which was causing the issue and removed from the gradle build. after that I am able to run build successfully.

Regards,
Gajendra

1 Like