Gradle says there is a conflict but then claims nothing uses the dependency

I’m trying to add a dependency on the snapshot version of elasticsearch. As soon as I try to build:

$ gradle idea
...omitting...

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':engine-impl:ideaModule'.
> Could not resolve all dependencies for configuration ':engine-impl:compile'.
   > A conflict was found between the following modules:
      - com.spatial4j:spatial4j:0.4.1
      - com.spatial4j:spatial4j:0.5

That’s cool, let’s see what depends on it.

$ gradle dependencyInsight --dependency com.spatial4j:spatial4j
:dependencyInsight
No dependencies matching given input were found in configuration ':compile'

BUILD SUCCESSFUL

Well, there should be no problem then, right?

Hey,

the dependencyInsight task you’re invoking is running on the root project, not on the project that caused the build to fail. Can you retry it with gradle :engine-impl:dependencyInsight --dependency com.spatial4j:spatial4j

$ gradle :engine-impl:dependencyInsight --dependency com.spatial4j:spatial4j
[buildinfo] Not using buildInfo properties file for this build.
:engine-impl:dependencyInsight FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':engine-impl:dependencyInsight'.
> Could not resolve all dependencies for configuration ':engine-impl:compile'.
   > A conflict was found between the following modules:
      - com.spatial4j:spatial4j:0.4.1
      - com.spatial4j:spatial4j:0.5

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Total time: 10.363 secs

I’m not sure about you, but I would prefer diagnostic tools not to fail with a problem which was the exact thing I was trying to diagnose.

But hey, at least the output is different. Now tell me how this is supposed to help.

Also if a command is going to fail when run on the top-level project, I would like the corresponding diagnostic tool to give useful information when run on the top-level project as well. How am I supposed to know that I had to run that on a subproject? :confused:

Hey,

  1. I changed the title of your post. The motivation was not to maintaining a fallacy that Gradle solves this issue, but to make the title more expressive and easier for other Gradle users who run into the same issue. The intention here was not to censoring anything. We know that dealing with builds can be build hell. We’ve all have been there

  2. As mentioned dependencyInsight is always running on the current project when invoked. In your first build output you can see that this resolves to executing :dependencyInsight meaning the dependencyInsight task of the root project. The task description of dependencyInsight when running gradle tasks tells you exactly that and is explicit about which project is evaluated here. Furthermore you can read that the resolution of :engine-impl dependencies is failing.

  3. I agree with you that dependencyInsight should do a better job when dealing with failOnVersionConflict set and diagnosing conflicting dependencies. This issue was raised before in another thread at Cannot use dependencyInsight report when resolution fails on a dependency version conflict and we have an open jira ticket GRADLE-3033 to track this. This hasn’t been high prioritized so far but we finally have the bandwidth to deal better with this kind of issues raised by the Gradle community. Please vote for this issue.

cheers,
René

That ticket… doesn’t seem like it will ever be fixed. It has been there for over a year without being addressed. I voted anyway, because really, what is the point of having a feature that fails in the only situation where anyone would ever use it? dependencyInsight might as well be removed in its current state.

Also, I think that editing posts to remove attitude reduces the expressiveness of posts. Gradle paints a false picture of “solving all problems” in all its marketing material, but in our project, it has been nothing but the cause of additional build problems. All the difficult things in our build are still difficult and it has added additional difficulties on top. Ant at least worked - it didn’t try to be clever and then fall over every time it tried. It had horrid bugs too, of course, but it was a system which we had all gotten used to so it worked.

Anyway, I believe that having posts in forums which show people as frustrated with the build system paints a more accurate picture of reality. Editing this out does basically amount to censorship and paints a picture that the Gradle devs are trying to cover up the fact that there are people whose projects have been more or less reduced to being unmanageable since it was introduced.

As a workaround you could

  1. Comment out failOnVersionConflict()
  2. Run gradle dependencyInsight
  3. Look for spatial4j dependencies
  4. Resolve accordingly