一、背景
1.假设我们现在有一个多模块的项目，依赖关系如图，我们在st-web模块中引入st-dal依赖时，st-common-lib这个依赖也会被我们引入，这个就是依赖传递，下表列出了scope在依赖过程中发生的变化，列标题为被依赖的模块，每行为要依赖的模块。
2.上面的就是关于依赖传递的。
二、依赖仲裁
1.（依赖仲裁）依赖冲突：就是我们当项目中引入的jar包，groupId(公司域名倒过来)和artifactId(功能命令)一样，但是version不一样的时候，这时候应该选择哪一个的version版本，这个就是叫依赖冲突。那我们怎么解决依赖冲突就有下面的这几种方法。
1.1.最短路径原则
假如说我们现在的项目依赖关系如图，那么maven会选用st-common-lib的那个版本呢，当然答案是st-common-lib（1.1）这个版本，st-web到st-common-lib(1.1)的距离为1，到st-web到st-common-lib(1.0)的距离为2，选择距离最短的，即最短路径原则。如何看依赖关系呢（mvn dependency:tree > show.txt），执行下这个命令就可以打印出全局的依赖数。
1.2.声明优先原则
项目依赖如图，路径一样，这又该怎么选择了呢，这就看你的pom.xml文件中先声明的那个依赖了，如果st-remote-invoker写在前面就使用st-common-lib(1.0)这个版本，如果st-dal写在前面就使用st-common-lib(1.1)这个版本。
1.3.依赖排除
去掉间接引入的jar包
举个例子：如果不想使用springboot默认提供的log，想集成第三方的log时或者说上面仲裁的第二个例子中，只想用st-common-lib的1.1版本，就可以吧1.0版本的排除掉。
三、总结
1.jar包冲突时时，maven有自己的依赖仲裁机制，优先选择路径近的，如果路径一样则选择谁先申明的。如果maven自己处理之后，项目还是启动和运行报错，就要人工进行排除了。
