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

Spring data gemfire 1.7.0.RELEASE对版本1.7.12有slf4j-api和jcl-over-slf4j有编译时间依赖性。我在Maven的POM文件中定义的下面的依赖，因为我们需要SLF4J 1.7.10依赖（其他几个罐子依赖于此）：maven如何解决spring数据gemfire的slf4j依赖问题？

<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回购作为Maven的中央存储库。下面是我在不同的场景看，基于什么罐子的行为在Maven中央可供选择：

我的问题：

在方案1，我不明白为什么构建没有抱怨缺少1.7.12 jar。如何解决依赖关系？
在场景2中，1.7.10 jar如何在1.7.12中覆盖1.7.12，而没有在弹簧数据依赖关系中为slf4j 1.7.12指定一个排除？
在场景3中，当maven中央缺少slf4j-parent 1.7.12的pom时，它为什么会投诉？由于1.7.10罐子存在，所以1.7.10罐子（类似于情况1）不应该运行良好吗？

来源

2015-12-22 Anand Jayabalan

答案是基于Maven Dependencies Mediation机制，特别是这样的说法：

You can always guarantee a version by declaring it explicitly in your project's POM

所以，本质上，通过明确声明它作为你的依赖的一部分，你将覆盖在传递依赖的任何版本，这样你就不需要添加任何排除。你声明它，你有这个项目的知识，Maven相信你。

所以在场景1和2中，Maven应用了上面的规则，并遵循POM中指定的规则。
在场景，因为它根本没有找到任何1.7.12版本，它甚至没有试图解决它，并信任你的POM。
在场景中，它解析了1.7.12的依赖关系树，但是基于你的POM，版本1.7.10获胜。
在场景它无法解决版本1.7.12的整个依赖关系树，因此它给出了一个错误：是的，你的POM的版本将赢得任何，但因为Maven有一个错误获取完全依赖树，它然后执行失败。

虽然这是一个特殊情况，但最终确认只能通过查看您正在使用的Maven版本的相关代码给出。

更新
我会建议在三种情况下要尽量有更多的细节，是从控制台运行：

mvn dependency:resolve -Dsort=true -X

由于调试标志，它将提供在相关性中介过程中包含和排除的依赖关系列表。

作为补充，运行：

mvn dependency:tree

会给你完整的依赖关系图，展示了实际上从POM采取什么通过传递依赖来了。这可能会给你更多的信息。欲了解更多详情，我建议看看Maven Dependency Plugin的目标。

来源

2015-12-22 09:50:20

谢谢。在场景1中，它不应该尝试解析1.7.12的依赖关系树吗？ –

事实上，这仍然是我唯一不清楚的地方，如果依赖关系根本不存在，并且POM覆盖它，或者如果它存在，它可能会有不同的行为，它会开始处理它，然后由于缺少部分而失败在依赖关系图中。你使用的是哪个版本的maven？ –

我更新了我的答案并提供了更多详细信息。 –

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

回答

相关问题