一、背景介绍
Java的强大之处就是在于它的生态环境,有众多的第三方服务支持复杂项目的开发。基本上每个稍微有点规模的Java项目都会依赖到众多的jar包,而Maven应该是目前管理jar包依赖最流行的工具。

二、知识剖析
Maven采用“最近获胜策略(nearest wins strategy)”的方式处理依赖冲突。换句话说,如果一个项目依赖于相同artifact的多个版本,在“依赖树”中离项目最近的那个版本将被使用。

三、常见问题

现在有一个web应用resolve-web。

4个jar包:project-A,project-B,project-C,project-Common。

maven Mongo驱动依赖 maven依赖管理插件_java


首先,我们针对只有sayHello()的 project-common,设置其版本为1.0,并执行mvn install。然后对其添加 sayGoodBye 方法,更改版本为2.0,执行mvn install。

现在,本地仓库同时有了project-common 1.0和2.0的jar包。它们将分别被project-C 和 project-A 所依赖。

maven Mongo驱动依赖 maven依赖管理插件_java_02


resolve-web 依赖于project-A和project-B,

project-A依赖于project-common1.0的jar包,调用了其中的sayHello()方法。

package project.common;
//project-common的1.0版本
public class HelloWorld {
    public String sayHello() {
        return "hello world";
    }
}
package projectA;

import project.common.HelloWorld;

public class HelloService {

   private HelloWorld helloWorld;
   public HelloService(HelloWorld helloWorld) {
       this.helloWorld = helloWorld;
   }

   public String sayHello() {
       return helloWorld.sayHello();
   }
}

project-B依赖于project-C,而project-C又进一步依赖于project-common2.0的jar包,并调用其中的sayGoodBye()方法。

package project.common;

public class HelloWorld {
//project-common的1.0版本
    public String sayHello() {
        return "hello world";
    }
    public String sayGoodBye(){
        return "Good Bye";
    }
}

project-common的1.0和2.0版本唯一区别在于,1.0中包含sayHello()方法,而2.0中包含了sayHello()和sayGoodBye()两个方法。

根据maven的依赖传递机制,虽然 resolve-web 并未直接引用project-common,但 B 依赖的 C 依赖了 common,所以 web 项目最终依赖了 common 。同理,web 项目也经由 A 依赖了 common。
C 的 pom.xml 中:

<dependency>
            <groupId>project-common</groupId>
            <artifactId>project-commmon</artifactId>
            <version>2.0</version>
 </dependency>

A 的 pom.xml中:

<dependency>
            <groupId>project-common</groupId>
            <artifactId>project-commmon</artifactId>
            <version>2.0</version>
</dependency>

现在整个项目的依赖图呈现这样的效果:

maven Mongo驱动依赖 maven依赖管理插件_maven_03


或者,在 resolve-web 目录下执行 “mvn dependency:tree -Dverbose”

maven Mongo驱动依赖 maven依赖管理插件_xml_04


也就是表明,project-C 虽然在 pom 中指明了其依赖的是 project-common-2.0,但根据maven的“近者优胜”策略,实质上它引用的是1.0。所以这会造成什么后果呢?

让我们启动 resolve-web 项目,并访问它的两个servlet,它们分别调用了 1.0和2.0 共有的sayHello() 方法 和2.0特有的sayGoodBye()方法。

在访问goodbye路径时报了错:

maven Mongo驱动依赖 maven依赖管理插件_xml_05


对于这种有依赖冲突所导致的问题,我们有两种解决方法。

方法1:
显式加入对project-common 2.0版本的依赖。
先前的2.0版本不是离resolve-web远了点吗,那我们就直接将它作为resolve-web的依赖,这不就比1.0版本离resolve-web还近吗?
在resove-web的pom.xml文件中直接加上对project-common 2.0 的依赖就好了。

方法2:

resolve-web对project-A的dependency声明中,将project-common排除掉。在resolve-web的pom.xml文件中修改对project-A的dependency声明:

maven Mongo驱动依赖 maven依赖管理插件_xml_06


方法2是不是有一点巧妙呢?虽然project-common被排除在project-A的dependency声明中了,但 project-A 自身的 pom 文件中依然存在对 project-common 1.0 的依赖。导致了 maven 最终会将2.0作为project-c的依赖。对于方法2的解决方式,下面推荐一款IDEA插件:

MavenHelper

maven Mongo驱动依赖 maven依赖管理插件_jar包_07


安装成功后打开pom文件就会在底部多一个[Dependency Analyzer]的选项。

maven Mongo驱动依赖 maven依赖管理插件_maven_08


使用

Conflicts(查看冲突)

All Dependencies as List(列表形式查看所有依赖)

All Dependencies as Tree(树形式查看所有依赖)

点击[Dependency Analyzer]选项,Conflicts会列出当前项目所有有冲突的依赖。

maven Mongo驱动依赖 maven依赖管理插件_maven_09


右击冲突插件要排除的版本,选择Exclude就可以将不要的版本排除。

maven Mongo驱动依赖 maven依赖管理插件_java_10


pom文件将自动生成exclusions代码,使用起来真是方便极了。

maven Mongo驱动依赖 maven依赖管理插件_java_11

参考链接:https://www.jianshu.com/p/106ef1150cf6
参考链接:http://www.duocaichajian.com/plugin/34.html