【摘要】：Maven在不同的生命周期使用的classpath是不同的，例如执行项目的测试和Maven项目运行的时候，这两者之间的classpath是有差异的。Maven的依赖范围与classpath的关系见表2-6。表2-6 scope范围根据上面的信息，可以轻松地引入其他构件，协助开发程序。如果依赖没有声明依赖范围，那么其依赖范围就是默认的compile。参照表2-7，第一直接依赖为compile，第二直接依赖为runtime，因此B对项目Proj是一个范围为runtime的传递性依赖。
Maven在不同的生命周期使用的classpath是不同的，例如执行项目的测试和Maven项目运行的时候，这两者之间的classpath是有差异的。常用的JUnit构件就是如此，在测试阶段会引入，但在运行Maven项目的时候是不需要的。
Maven的依赖范围与classpath的关系见表2-6。
表2-6 scope范围
根据上面的信息，可以轻松地引入其他构件，协助开发程序。在引用其他依赖时如果出现引用冲突，可以通过Maven的传递性依赖解决这一问题。
如果依赖没有声明依赖范围，那么其依赖范围就是默认的compile。假如A依赖B，B依赖C，那么A对B是第一直接依赖，B对C是第二直接依赖，A对C是传递性依赖。第一直接依赖范围和第二直接依赖范围决定了传递性依赖的范围。(www.xing528.com)
在表2-7中，左边第一列表示第一直接依赖范围，最上面一行表示第二直接依赖的范围，中间的单元格表示传递性依赖范围，表格中的“-”表示依赖无法传递。
表2-7 依赖传递
根据上面的规则举例，例如项目Proj中，有一个直接依赖A，其依赖范围为compile，而A依赖里面又有一个B的直接依赖，其依赖范围为runtime，那么显然B是Proj项目的传递性依赖。参照表2-7，第一直接依赖为compile，第二直接依赖为runtime，因此B对项目Proj是一个范围为runtime的传递性依赖。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
