Maven传递依赖冲突解决（版本冲突）

1、首先要明白直接依赖和传递依赖的概念：

    A > B > C

直接依赖：A > B , B > C

传递依赖：A > C

2、冲突产生的缘由：spring-jdbc和context同时依赖于spring-beans，若是jdbc和context的版本不一致，那相应的spring-beans版本便也不一致，此时应该依赖哪一版本的spring-beans呢，这便产生了依赖冲突。

3、冲突的解决方案：

    一、Maven本身调解原则：

        （1）第一声明者优先原则（谁先定义就用谁的传递依赖）

        （2）路径近者优先原则（直接依赖级别高于传递依赖）

    二、排除依赖：

        在pom.xml中将冲突的依赖排除

        

            

        （也可在dependencies查看中将spring-beans  jar包右键选择exclution Maven artifct）

    三、版本锁定（推荐使用）：

        

 

        还能够将版本属性统一配置：

        

 

4、使用IntelliJ IDEA工具

    使用IDEA原生的jar包冲突解决可参考：详述使用 IntelliJ IDEA 解决 jar 包冲突的问题
    使用Maven Helper插件：idea 中解决maven 包冲突的问题（maven helper）（相对原生工具更好用）

 

 

如下为摘录内容：（原贴：https://www.oschina.net/question/698806_159139，https://www.cnblogs.com/wangyonghao/p/5976055.html）

• groupId：定义当前 Maven 项目所属的实际项目，跟 Java 包名相似，一般与域名反向一一对应；
• artifactId：定义当前 Maven 项目的一个模块，默认状况下，Maven 生成的构件，其文件名会以 artifactId 开头，如 hibernate-core-3.6.5.Final.jar；
• version：项目版本；
• packaging：定义项目打包方式，如 jar，war，pom，zip ……，默认为 jar；
• classifier：定义项目的附属构件，如 hibernate-core-3.6.6.Final-sources.jar，hibernate-core-3.6.6.Final-javadoc.jar，其中 sources 和 javadoc 就是这两个附属构件的 classifier。classifier 不能直接定义，一般由附加的插件帮助生成；
• type：依赖类型，对应构件中定义的 packaging，可不声明，默认为 jar；
• scope：依赖范围；
• optional：依赖是否可选；
• exclusions：排除传递依赖；
• systemPath：本地jar文件路径。

MAVEN Scope使用

在Maven的依赖管理中，常常会用到依赖的scope设置。

Scope的使用场景和说明
1.compile
编译范围，默认scope，在工程环境的classpath（编译环境）和打包（若是是WAR包，会包含在WAR包中）时候都有效。
 
2.provided
容器或JDK已提供范围，表示该依赖包已经由目标容器（如tomcat）和JDK提供，只在编译的classpath中加载和使用，打包的时候不会包含在目标包中。最多见的是j2ee规范相关的servlet-api和jsp-api等jar包，通常由servlet容器提供，无需在打包到war包中，若是不配置为provided，把这些包打包到工程war包中，在tomcat6以上版本会出现冲突没法正常运行程序（版本不符的状况）。
 
3.runtime
通常是运行和测试环境使用，编译时候不用加入classpath，打包时候会打包到目标包中。通常是经过动态加载或接口反射加载的状况比较多。也就是说程序只使用了接口，具体的时候可能有多个，运行时经过配置文件或jar包扫描动态加载的状况。典型的包括：JDBC驱动等。
 
4.test
测试范围，通常是单元测试场景使用，在编译环境加入classpath，但打包时不会加入，如junit等。
 
5.system 系统范围，与provided相似，只是标记为该scope的依赖包须要明确指定基于文件系统的jar包路径。由于须要经过systemPath指定本地jar文件路径，因此该scope是不推荐的。若是是基于组织的，通常会创建本地镜像，会把本地的或组织的基础组件加入本地镜像管理，避过使用该scope的状况。   实践： 　　• provided是没有传递性的，也就是说，若是你依赖的某个jar包，它的某个jar的范围是provided，那么该jar不会在你的工程中依靠jar依赖传递加入到你的工程中。 　　• provided具备继承性，上面的状况，若是须要统一配置一个组织的通用的provided依赖，可使用parent，而后在全部工程中继承。