maven如何解决spring数据gemfire的slf4j依赖？

Question

弹簧数据gemfire 1.7.0对版本1.7.12 of slf4j-api和jcl-over-slf4j具有编译时依赖关系。我在maven pom文件中定义了以下依赖项，因为我们需要slf4j 1.7.10依赖项(很少有其他jars依赖于此)：

<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>

我有一个内部maven repo作为Maven中央存储库。下面是我在不同场景中看到的基于maven中心可用的jars的行为：

​

​

我的问题：

1. 在场景1中，我不明白为什么构建没有抱怨缺少1.7.12 jar。依赖是如何解决的？
2. 在场景2中，1.7.10 jar如何在不指定slf4j 1.7.12的春季数据依赖项的情况下覆盖1.7.12？
3. 在场景3中，当slf4j-父1.7.12的pom丢失在Maven central中时，它为什么会抱怨呢？既然存在1.7.10 jars，那么构建是否应该很好地获取1.7.10 jars (类似于场景1)？

Answer 1

答案基于Maven依赖调解机制，特别是以下语句：

始终可以通过在项目的POM中显式声明版本来保证版本

因此，从本质上说，通过显式声明它是依赖关系的一部分，您就可以在传递依赖项上重写任何版本，因此不需要添加任何排除。您声明它，您了解该项目，Maven信任您。

因此，在场景1和2中，Maven应用了上面的规则，并遵循了POM中指定的规则。

在场景1中，由于它根本没有找到任何1.7.12版本，所以它甚至没有尝试解决它并信任您的POM。

在场景2中，它解析了1.7.12的依赖关系树，但是根据您的POM，版本1.7.10胜利了。

在场景3中，它无法解析1.7.12版本的整个依赖树，因此给出了一个错误:是的，您的POM的版本无论如何都会赢，但是由于Maven在获得完整的依赖树时出错，所以它失败了。

不过，这是一个特例，最后的确认只能查看您正在使用的Maven版本的相关代码。

更新

为了了解更多细节，我建议在这三种场景中尝试从控制台运行：

mvn dependency:resolve -Dsort=true -X

由于使用了调试标志，它将在依赖关系调解过程中提供包含依赖项和排除依赖项的列表。

作为补充，运行：

mvn dependency:tree

将给出完整的依赖关系图，显示从POM中实际获取的内容和传递依赖关系的结果。这可能会给你更多的信息。关于更多的细节，我建议看看Maven依赖插件的目标。