项目开发过程中经常会碰到maven依赖冲突的问题，这篇post整理下maven依赖冲突产生的原因以及解决方案
maven依赖冲突的产生是由maven传递性依赖造成的：
什么是maven传递依赖？
“一个传递性依赖就是对于一个依赖的依赖。如果project-a依赖于project-b，而后
者接着依赖于project-c，那么project-c就被认为是project-a的传递性依赖。如
果project-c依赖于project-d，那么project-d就也被认为是project-a的传递性依
赖。Maven的部分吸引力是由于它能够管理传递性依赖，并且能够帮助开发者屏蔽掉跟
踪所有编译期和运行期依赖的细节。你可以只依赖于一些包如Spring Framework，而不
用担心Spring Framework的所有依赖，Maven帮你自动管理了，你不用自己去详细了解
配置。
Maven是怎样完成这件事情的呢？它建立一个依赖图，并且处理一些可能发生的冲突和
重叠。例如，如果Maven看到有两个项目依赖于同样的groupId和artifactId，它会自动
整理出使用哪个依赖，选择那个最新版本的依赖。虽然这听起来很方便，但在一些边界
情况中，传递性依赖会造成一些配置问题。在这种情况下，你可以使用依赖排除。”
——摘自《Maven权威指南》
什么情况下会产生依赖冲突？
举例说明：项目中的pom.xml里声明了对project-a1.0与project-b2.0的依赖，而project-a1.0又传递依赖于project-b1.0的版本。
假设maven经过分析之后决定使用project-b1.0的依赖，也就是打包的时候把project-b1.0.jar打进了war包。
war包部署在java容器中启动之后，如果依赖project-b2.0.jar中新添的类或方法，就会发现引用的类或者方法不存在。
这种现象就是依赖冲突。
如何分析依赖冲突？
mvn dependency:tree
冲突解决方案：
使用maven提供的<exclusion>标签。
举例说明：
如果你正依赖于一个类库，该类库又依赖于Sun JTA API，你会想要替换这个传递性依赖。
Hibernate是一个例子。Hibernate依赖于Sun JTA API，而后者在中央Maven仓库中不可用，因为它是不
能免费分发的。幸运的是，Apache Gernoimo项目创建了一些可以免费分发的独立实现
类库。为了用另外的依赖来替换这个传递性依赖，你需要排除这个传递性以依赖，然后
在你的项目中再声明一个依赖。下面展示了这样一个替换的样例。
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate</artifactId>
<version>3.2.5.ga</version>
<exclusions>
<exclusion>
<groupId>javax.transaction</groupId>
<artifactId>jta</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.apache.geronimo.specs</groupId>
<artifactId>geronimo-jta_1.1_spec</artifactId>
<version>1.1</version>
</dependency>