我的情况如下:
我使用maven作为构建过程。我正在创建一个Web项目,我想在其中使用特定版本的spring。该项目还依赖于第三方库,该库在内部依赖于不同版本的弹簧。我怀疑这会产生两个不同版本的spring n class-path,并会观察到意外的行为。我的信息很少,我希望得到更多的澄清。
如果有人可以点亮它并给出细节参考,那对我有很大的帮助。
答案 0 :(得分:0)
Maven应该知道如何驱逐一个或多个工件的冲突版本。 但是,您可以通过简单地排除传递中包含的依赖项之一来影响它。 示例:以下代码排除了io.netty(传递)依赖项。通过这种方式,您可以根据自己的喜好选择其他版本的maven。
<dependency>
<groupId>org.apache.hbase</groupId>
<artifactId>hbase-client</artifactId>
<version>${hbase.version}</version>
<!-- The exclusion below makes sure that this specific version imported by hbase does not end up deployed -->
<exclusions>
<exclusion>
<artifactId>netty</artifactId>
<groupId>io.netty</groupId>
</exclusion>
</exclusions>
</dependency>
关于运行时行为,您必须自己测试并做出决定(也就是说,如果您没有幸运的话,您可以获得记录其自身依赖项版本的直接工件)
答案 1 :(得分:0)
您可以使用BOM的概念,但这不能避免库本身的冲突问题。项目有一个或多个库依赖于不同版本的同一个库是很常见的。在这种情况下,当您要为该第三方库强制某些特定的库版本时,必须使用&lt;在POM中显示它。排除&gt;标记。一旦项目通常有很多库,这不是一件容易的事。因此,您需要一种工具来为您提供一种可视化项目库的依赖关系层次结构的简便方法。这有一些IDE插件。例如,某些版本的Eclipse中包含maven插件,它提供了一个依赖层次结构视图(一种图书馆及其依赖项)。一旦检测到不应该使用其他库依赖项的库(例如错误版本),就可以在pom中使用此依赖项并使用排除标记调整依赖项版本。使用该工具可以使这项任务变得非常简单。