How's maven resolving the slf4j dependency of spring data gemfire? - maven

Question

Spring data gemfire 1.7.0.RELEASE has compile time dependencies on version 1.7.12 of slf4j-api and jcl-over-slf4j. I have defined the below dependencies in my maven pom file, as we need slf4j 1.7.10 dependency (few other jars depend on this):
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-gemfire</artifactId>
<version>1.7.0.RELEASE</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.10</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>1.7.10</version>
<scope>runtime</scope>
</dependency>
I have an internal maven repo as the Maven central repository. Below is the behavior I see in different scenarios, based on what jars are available in the maven central:
My questions:
In scenario 1, I don't understand why the build didn't complain about missing 1.7.12 jar. How did the dependency get resolved?
In scenario 2, how's the 1.7.10 jar overriding the 1.7.12 without me specifying an exclusion for slf4j 1.7.12 in the spring data dependency?
In scenario 3, when the pom for slf4j-parent 1.7.12 is missing in Maven central, why does it complain? Since 1.7.10 jars are present, shouldn't the build run fine picking up the 1.7.10 jars (similar to scenario 1)?

Answer 1

The answer is based on the Maven Dependencies Mediation mechanism, specifically this statement:
You can always guarantee a version by declaring it explicitly in your project's POM
So, essentially, by explicitly declaring it as part of your dependencies, you are overriding any version on transitive dependencies, as such you don't need to add any exclusion. You declare it, you have the knowledge of the project, Maven trusts you.
So in scenario 1 and 2 Maven applied the rule above and just followed what is specified in the POM.
In scenario 1, since it didn't find any 1.7.12 version at all, it even didn't try to resolve it and trusted your POM.
In scenario 2, it resolved the dependencies tree of 1.7.12, but then based on your POM, the version 1.7.10 won.
In scenario 3 it couldn't resolve the whole dependency tree of version 1.7.12 and as such it gave an error: yes, the version from your POM would have won anyway, but since Maven had an error on getting the full dependency tree, it then failed its execution.
This is a special case though, and final confirmation could only be given looking at the concerned code of the Maven version you are using.
Update
What I would suggest to try in the three scenarios to have a bit more of details, is to run from the console:
mvn dependency:resolve -Dsort=true -X
Thanks to the debug flag, it will provide a list of included and excluded dependencies during the Dependency Mediation process.
As a complement, running:
mvn dependency:tree
Would give you the full dependency graph, showing what was actually taken from the POM and what came through transitive dependencies. That might give you further info. For further details, I would suggest to have a look at the Maven Dependency Plugin goals.