Resolution with project dependencies can lead to > Module version circleđź…±unspecified, configuration 'default' declares a dependency on configuration 'default' which is not declared in the module descriptor for circleđź…°unspecified

Old Forum Archive Bugs
1

Reduced example here: https://github.com/rspieldenner/gradleresolveissue

If I have project A with build.gradle

dependencies {
  testCompile project(':b')
}

and project B with build.gradle

dependencies {
  compile project(':a')
}

in a multiproject with build.gradle

subprojects {
  apply plugin: 'java'

  project.gradle.projectsEvaluated {
    configurations.all { Configuration config ->
      resolutionStrategy {
        def copy = config.copyRecursive()
        if (copy.resolvedConfiguration.hasError()) println 'error'
        // do actual work with dependencies of this copied configuration
      }
    }
  }
}

I can’t resolve the project where if I leave off the configurations block it works fine.

2

Hey Rob, which version of Gradle are you seeing this issue in?

3

I’ve tried 2.10 through 2.13-rc-1

4

Hi Rob,

There definitely is something wrong going on with copies of configurations that contains project dependencies cycles. The cycling dependency refer to the original configuration hence the resolution failure.
This is a known issue, see https://issues.gradle.org/browse/GRADLE-3280

In the meantime, is there any chance your use case can be implemented without relying on configurations copies?

5

I’m resolving the configuration copy to get a full list of direct and transitive dependencies and what version they are in order to figure out what the semantically latest version is and pull them all up to that level.

Example: I want jersey-core, jersey-client, and jersey-server to be at the same version. I depend on jersey-server 1.19, somebody I depend on uses jersey-client 1.19.1 and one of my other libraries uses jersey-core 1.18 and I want to create a resolutionRule on the fly to align all 3 of them to 1.19.1 (but I don’t know I want 1.19.1 until after the resolve).

We found a workaround by excluding ourselves from the copied configuration.

6

Thanks for the context, nice use case for resolution rules!
Good to read that you worked around the issue.
You may want to watch the JIRA to follow up.