Maven Dependency scope

scope的分类

• compile（编译依赖范围）：如果没有指定，就会默认使用该依赖范围，使用此依赖范围的Maven依赖，对于编译，测试，运行三种classpath都有效。
• test（测试依赖范围）：使用此依赖范围的Maven依赖，只对于测试classpath有效，在编译主代码或者运行项目的使用时将无法使用此类依赖，典型例子是JUnit，它只有在编译测试代码及运行测试的时候才需要。
• runtime（运行时依赖范围）：使用此依赖范围的Maven依赖，对于测试和运行classpath有效，但在编译主代码时无效，典型例子是JDBC驱动实现，项目主代码的编译只需要JDK提供的JDBC接口，只有在执行测试或者运行项目的时候才需要实现上述接口的具体JDBC驱动。
• provided（已提供依赖范围）：使用此依赖范围的Maven依赖，对于编译和测试classpath有效，但在运行时无效，典型例子是servlet-api，编译和测试项目的时候需要该依赖，但在运行项目的时候，由于容器已经提供，就不需要Maven重复地引入一遍。
• system（系统依赖范围）：该依赖与三种classpath的关系，和provided依赖范围完全一致，但使用system范围依赖时必须通过systemPath元素显式地指定依赖文件的路径，由于此类依赖不是通过Maven仓库解析的，而且往往与本机系统绑定，可能造成构建的不可移植，因此应该谨慎使用。
• import(Maven 2.0.9及以上）：导入依赖范围，该依赖范围只能与 dependencyManagement 元素配合使用，其功能是将目标 pom.xml 文件中 dependencyManagement 的配置导入合并到当前 pom.xml 的 dependencyManagement 中。

scope的依赖传递

• 项目 A 依赖于项目 B,B 又依赖于项目 C，此时我们可以将 A 对于 B 的依赖称之为第一直接依赖，B 对于 C 的依赖称之为第二直接依赖。
• B 是 A 的直接依赖，C 是 A 的间接依赖，根据 Maven 的依赖传递机制，间接依赖 C 会以传递性依赖的形式引入到 A 中，但这种引入并不是无条件的，它会受到依赖范围的影响。
• 传递性依赖的依赖范围受第一直接依赖和第二直接依赖的范围影响。

• 通过上表，可以总结出以下规律：
  • 当第二直接依赖的范围是 compile 时，传递性依赖的范围与第一直接依赖的范围一致。
  • 当第二直接依赖的范围是 test 时，传递性依赖不会被传递。
  • 当第二直接依赖的范围是 provided 时，只传递第一直接依赖的范围也为 provided 的依赖，且传递性依赖的范围也为 provided
  • 当第二直接依赖的范围是 runtime 时，传递性依赖的范围与第一直接依赖的范围一致，但 compile 例外，此时传递性依赖的范围为 runtime