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.