IDE Gradle plugin does not do conflict resolution

Bugs
1

The gradle tooling API does not seem to resolve conflicts. If multiple versions of the same dependency appear on the classpath, Gradle will do conflict resolution, but the tooling API does not seem to do so. This causes Gradle to supply a different classpath than the local IDE run would.

To reproduce:

  1. new gradle project in IDEA
  2. create two modules, example-a and example-b
  3. example-a/build.gradle declares
dependencies {
    compile('com.google.inject:guice:3.0')
}
  1. example-b/build.gradle declares
dependencies {
    compile('com.google.inject:guice:4.0-beta5')
    compile project(":example-a")
}
  1. observe that gradle builds example-b using guice 4.0, but IDEA will build using guice 3.0.While Gradle conflict resolution chooses the latest version and only put that on the classpath. IDEA gets both versions on the classpath for some reason, and so it picks the first it finds – usually the earliest version since dependencies are ordered lexicographically.
    If this doesn’t cause a compile error, then IDEA will silently use different dependencies than the real gradle build will, which is dangerous for local testing.
    Both Eclipse and IDEA have this problem, which leads me to believe it’s the backing tooling API causing it. Ideally gradle should export only one version of any dependency, ever, and pick that version via the configured conflict resolution.
2

This is really a result of the way Idea handles dependencies. If you look at the module dependencies for ‘example b’ in IntelliJ, you’ll notice that the correct version is indeed listed. However, the exported dependency from ‘example a’ is taking precedence due to ordering. The best solution here really is to standardize versions across your projects rather than rely on conflict resolution to do this for you.

There are actually other considerations too since in the current state you are testing against one version of guice yet using a completely different version at runtime.

3

Am I incorrect in thinking that Gradle tooling should be exporting only one version of each dependency?

4

The tooling API is returning the correct dependencies. It is returning the ‘example-a’ module as well as guice 4.0-beta5. It just happens that Idea orders module dependencies first, therefore 3.0 happens to win (as it is exported by ‘example-a’). We can’t simply not export the other version because other modules (that don’t specify their own version of guice) might need it.

5

Ah, alright. Thought that the api would resolve the module’s dependencies and export them all rather than just contain a reference. Thanks for your help.