一：问题出现场景

记得有一次，面试时候面试官问了个问题，来哥们，“你们项目是maven搭建哈，你的项目里如果出现架包冲突了，你们怎么解决的？”。

我：......，装作很淡定，我们是通过报错，定位哪个架包出问题。

二：场景复现

A依赖于B及C，而B又依赖于X、Y，而C依赖于X、M，则A除引B及C的依赖包下，还会引入X，Y，M的依赖包。
这里有一个需要特别注意的，即B和C同时依赖于X，假设B依赖于X的1.0版本，而C依赖于X的2.0版本，A究竟依赖于X的1.0还是2.0版本呢？
这就看Classloader的加载顺序了，假设Classloader先加载X_1.0，而它就不会再加载X_2.0了，如果A恰恰希望使用X_2.0呢，血案就这样不期而遇了。

三：解决方法

1）第一斧

我们可以通过mvn dependency:tree来查询项目中所有架包依赖控制台打印，或者我们mvn dependency:tree > D:/tree.txt 输入文件

当然第一斧头没这么简单，如果我们项目依赖架包很多，控制台肯定存放不了对吧。那么我们就可以通过 mvn dependency:tree -Dverbose -Dincludes

=groupId:artifactId:version 定位具体哪个架包出现问题。

mvn dependency:tree 按照树形结构输出架包，还可以是 dependency:list

-Dverbose 展示所有引用架包，包括重复引用的或者忽略的

-Dincludes 精确查询到某一个架包

　　如上两个commons-logging，通过不同的架包引入

　　2）第二斧

去除掉重复引入的架包。   　　<dependency>

    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
    <version>${spring.version}</version>
    <!--这里是关键去除的地方-->
    <exclusions>
        <exclusion>
            <groupId>commons-logging</groupId>
            <artifactId>commons-logging</artifactId>
        </exclusion>
    </exclusions>
</dependency>

　　3）第三斧
      常见maven优化
      1.优化依赖以及分析
        mvn dependency:analyze

　　　　[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
　　　　[ERROR] Re-run Maven using the -X switch to enable full debug logging.
　　　　[ERROR] For more information about the errors and possible solutions, please read the following articles:
　　　　[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

2.归类依赖

在父pom文件中，会${springframwork.version}声明出版本，统一进行版本升级，如下所示

　　　　<gravitee-node.version>1.5.0</gravitee-node.version>
　　　　<gravitee-definition.version>1.18.0</gravitee-definition.version>
　　　　<gravitee-common.version>1.15.0</gravitee-common.version>

　　 3.依赖调节

第一原则：路径最近者优先；
　　　　第二原则：路径长度一样时，第一声明者优先。

另外常用的安装jar到自己服务器的命令为:

mvn install:install-file -DgroupId=novaplanet.net -DartifactId=commons-lang -Dversion=2.5 -Dfile=F:/commons-lang-2.5.jar -Dpackaging=jar -DgeneratePom=true