How do I debug *why* a dependency was overridden?

I had a problem where Gradle was overriding the version of a dependency of one of my explicitly specified libraries with a version from an indirect dependency of a different library.

I used the “dependencies” task to debug it - and it did show me that my library was being overridden.
But that’s where I got stuck. I couldn’t figure out why Gradle was overriding the dependency.

Is there any way to get Gradle to show me what caused a dependency version to be overridden?
The only way I could see to do that would be to manually trawl through all the dependencies looking for any library, or transitively included library that specified a direct dependency to the overriding version. That’s not very practical.

Here is a link to the Stack Overflow question that I posted to try and diagnose the problem, it has a more detailed description of the specific issue I was trying to debug:

I just found Peter’s answer to a similar question here:
That answer explicitly says “answering this question is the whole point of the dependencyInsight task”.

Here is a link to the result of running the dependencyInsight task on my project:

It looks the same as the output of the dependencies task to me.

I also tried ./gradlew :api-svc:dependencyInsight --configuration compile --dependency jooq, which gave:

project :api-svc:jooq
\--- compile

org.jooq:jooq:3.9.5 (selected by rule)

org.jooq:jooq:3.10.1 -> 3.9.5
\--- project :api-svc:jooq
     \--- compile

1 actionable task: 1 executed

This indicates that the version was selected explicitly in your gradle logic. This logic lives either in your build script or in the plugins you apply. My best guess is that you use the spring dependency management plugin somehow that enforces this particular version.

Would you mind sharing a build scan of your project build? That would allow us to see what exact dependencies and plugins have been used than using dependencyInsight.


Yes - as indicated in the SO comment from Lukas, the problem is likely spring-boot.
But he only knew that because someone else had a similar problem.

I’ve PM’d you the build scan link.