Question

My project depends on library A in version n.
It also depends on library B, which in turn depends on A in a version n-1.

When running gradle dependencies the tree shows my project and B both depending on A in version n.

However, when I run gradle idea I get a workspace with both version n and n-1 reported.

Can I do anything to circumvent it and have get a idea workspace that conforms to gradle’s dependeny resolution without forcing a version or changing the version I depend on?

I have already taken this to the Gradle list, but to no avail.

Update: I’ve uploaded a sample configuration, so you can experiment with it yourself. Note how Guava (A) appears in both version 10.0 and 11.0, thanks to both me and Reflections (B) depending on it.
From the example, I have learned that this only happens when the dependencies on A and B are spread across submodules.
Note: I know that Reflections 0.96 won’t work with Guava 11.0. It just was the first thing that came to mind.

Answer 1

Just to be able to close this, here’s what Peter Niederwieser wrote:

[This] is the expected behavior, not just for the IDEA plugin but for Gradle in general. This is because conflict resolution is currently done per configuration, not per build. When you execute gradle dependencies in Module1 and Module2, you’ll get the same results as for the IDEA modules.

If both modules use Guava directly, you should specify direct dependencies, which solves the problem. Often this is done by factoring out the dependency declarations into a parent build script and referencing them by name from child scripts. (This is somewhat similar to Maven’s dependencyManagement section.) Forcing a version for all configurations is another solution. I expect that future versions of Gradle will support build-wide conflict resolution.

Thanks for creating a sample project. This makes it so much easier to reproduce a problem. By the way, the best place to ask questions is http://forums.gradle.org.