Maven依赖规则和依赖范围

Part one：

 maven传递依赖的版本确定规则，也就是对重复的间接依赖的包的选择规则：

　　1. 在工程的依赖树上，深度越浅，越被优先选择。如本例中的spring-jms. 由于pom中直接声明了3.0.2版本的spring-jms,所以3.0.2版本的spring-jms在工程的依赖树上处在第一层，而activemq-optional所间接依赖的3.0.3版本的spring-jms则是处在工程依赖树的第二层，则maven会以深度浅者优先，所以最后解析的结果是选择了3.0.2版本的spring-jms。

　　2. 若两个依赖包处于依赖树上的同一层，则谁在前，选择谁。如本例中的spring-core.一个是activemq-optional的间接依赖，一个是spring-context的间接依赖，两个依赖都是处在第二层上，但由于是activemq-optional声明在前，所以maven优先选择了activemq-optional所依赖的3.0.3的版本！

　　3. 避免传递依赖引起版本问题的最佳实践。现在很多的开源框架和工具都开始分模块打包发布，比如spring,hibernate都是如此，而这些模块之间又有可能存在相关的依赖关系，为了避免出现版本不一致问题，比如上例中出现的spring-jms使用的是3.0.2，而spring-core却使用了3.0.3这种情况，需要我们对一个工程直接依赖的某一框架的多个模块都要做出声明，而不要依赖其内部的依赖关系来间接引入。总结起来就昌：一般来说，如果工程直接依赖到某一框架的多个模块，最好全部声明这些依赖。

Part two:

compile （编译范围）

compile是默认的范围；如果没有提供一个范围，那该依赖的范围就是编译范围(包括编译，测试，运行，打包都能用)。编译范围依赖在所有的classpath 中可用，同时它们也会被打包。

provided （已提供范围）

provided 依赖只有在当JDK 或者一个容器已提供该依赖之后才使用（编译，测试可用）。例如，如果你开发了一个web 应用，你可能在编译 classpath 中需要可用的Servlet API 来编译一个servlet，但是你不会想要在打包好的WAR 中包含这个Servlet API；这个Servlet API JAR 由你的应用服务器或者servlet 容器提供。已提供范围的依赖在编译classpath （不是运行时）可用。它们不是传递性的，也不会被打包。

runtime （运行时范围）

runtime 依赖在运行和测试系统的时候需要（运行时才可用），但在编译的时候不需要。比如，你可能在编译的时候只需要JDBC API JAR，而只有在运行的时候才需要JDBC
驱动实现。

test （测试范围）

test范围依赖在一般的编译和运行时都不需要，它们只有在测试编译和测试运行阶段可用。

system （系统范围）

system范围依赖与provided 类似，但是你必须显式的提供一个对于本地系统中JAR 文件的路径。这么做是为了允许基于本地对象编译，而这些对象是系统类库的一部分。这样的构件应该是一直可用的，Maven 也不会在仓库中去寻找它。如果你将一个依赖范围设置成系统范围，你必须同时提供一个systemPath 元素。注意该范围是不推荐使用的（你应该一直尽量去从公共或定制的 Maven 仓库中引用依赖）。

最左边一行表示第一直接依赖范围，最上面一行表示第二直接依赖范围，中间的交叉单元格则表示传递性依赖范围。

	compile	test	provided	runtime
compile	compile	---	---	runtime
test	test	---	---	test
provided	provided	---	provided	provided
runtime	runtime	---	---	runtime

仔细观察上面表格，我们发现这样的规律：

当第二直接依赖的范围是compile的时候，传递性依赖的范围与第一直接依赖的范围一致； 当第二直接依赖的范围是test的时候，依赖不会得以传递； 当第二直接依赖的范围是provided的时候，只传递第一直接依赖的范围也为provided的依赖，切传递性依赖的范围同样为provided； 当第二直接依赖的范围是runtime的时候，传递性依赖的范围与第一直接依赖的范围一致，但compile例外，此时传递性依赖的范围为runtime。