Maven依赖

依赖范围与classpath的关系

依赖范围(Scope)	对于编译classpath有效	对于测试classpath有效	对于运行时classpath有效	例子
compile	Y	Y	Y	spring-core
test	N	Y	N	Junit
provided	Y	Y	N	servlet-api
runtime	N	Y	Y	JDBC驱动实现

传递性依赖和依赖范围
依赖范围不仅可以控制依赖与三种classpath的关系，还对传递性依赖产生影响。accout-email对于spring-core的依赖范围是compile，是spring-core对于commons-logging的依赖范围是compile，那么account-email对于commons-logging这一传递性依赖的范围也就是compile。假设A依赖于B，B依赖于C,我们就说A对于B是第一直接依赖，B对于C是第二直接依赖，A对于C是传递性依赖。第一直接依赖的范围和第二直接依赖的范围决定了传递性依赖的范围，如下图，最左边一行表示第一直接依赖范围，最上面一行表示第二直接依赖范围，中间的交叉单元格则表示传递性依赖范围。

compile	test	provided	runtime
compile	compile	——	——
test	test	——	——
provided	provided	——	provided
runtime	runtime	——	——

举个例子。account-email项目有一个com.icegreen:greenmail:1.2.1b的直接依赖，我们就这是第一直接依赖，其依赖范围是test；而greenmail又有一个javax.mail:mail:1.4的直接依赖，我们就说这是第二直接依赖，其依赖范围是compile.显然javax.mail:mail:1.4是account-email的传递性依赖，对照上表可以知道，当第一直接范围是test，第二直接依赖范围是compile的时候，传递性依赖的范围是test，因此javax.mail:mail:1.4是account-email的一个范围是test的传递性依赖。
观察上表，我们可以发现这样的规律：当第二直接依赖的范围是compile的时候，传递性依赖的范围与第一直接依赖的范围一致；当第二直接依赖的范围是test的时候，依赖不会得以传递；当第二直接依赖的范围是provided的时候，只传递第一直接依赖范围也为provided的依赖，且传递性依赖的范围同样为provided；当第二直接依赖的范围是runtime的时候，传递性依赖的范围与第一直接依赖的范围一致，但compile例外，此时传递性依赖的范围为runtime。