Problem when resolving *->* ivy configuration mapping


(Matthieu Leclercq) #1

when a dependency in a ivy.xml does not specify the configuration mapping ‘->’ is used. It seems that with gradle this is not interpreted as with ivy.

For instance assuming we have existing ivy modules configured as :

  • one module with a single configuration called “foo” with one artifact

  • a second module with a configuration called “bar” with another artifacts

  • a dependency to the first module that does not specify conf mapping (or specify conf="->")

If I declare a dependency to the “bar” configuration of the second module, I expect to retrieve the artifact attached to the “bar” configuration of the second module, and the artifact attached to the “foo” configuration of the first module.

With ivy this is what I get, but with Gradle I get the following exception

Caused by: java.lang.RuntimeException: Module version group:…, module:‘second module’, version:…, configuration:bar declares a dependency on configuration ‘bar’ which is not declared in the module descriptor for group:…, module:‘first module’, version:…

at org.gradle.api.internal.artifacts.ivyservice.resolveengine.DependencyGraphBuilder$DependencyEdge.calculateTargetConfigurations(DependencyGraphBuilder.java:346)…

It seems that Gradle is trying to resolve the ‘bar’ configuration on the first module while this module has only one configuration called ‘foo’.

After running a test in debug, it seems that there is a bug at https://github.com/gradle/gradle/blob/master/subprojects/core-impl/src/main/groovy/org/gradle/api/internal/artifacts/ivyservice/resolveengine/DependencyGraphBuilder.java#L792

Indeed, when ‘->’ is specified as configuration mapping, the public configurations of the target module should be added in targetConfigurations list. But here it seems that the public configurations of the source module (i.e. the one that declare the dependency) that are added.


#2

Thanks for the detailed analysis. Would you be interested in submitting a patch for this?

For a patch to be useful it would need to include a set of integration tests that demonstrates this behaviour. You can see the current dependency resolution integration tests at https://github.com/gradle/gradle/tree/master/subprojects/core-impl/src/integTest/groovy/org/gradle/integtests/resolve