Maven依赖传递

背景

最近在学习《Maven实战》这本书，在看到依赖传递这部分的时候，我发现书本提供的依赖传递表有点不合理，就去官网看文档，最后发现官网提供的表和《Maven实战》提供的表不一致，我觉得一切要以官网的为准，同时参考了这篇文章的一部分内容，http://seanzhou.iteye.com/blog/1688740。

官网文档片段

摘抄日期为2015年5月13日，如果后续有变化，再说。

=======================================================================================

Dependency scope is used to limit the transitivity of a dependency, and also to affect the classpath used for various build tasks.

There are 6 scopes available:

• compile
  This is the default scope, used if none is specified. Compile dependencies are available in all classpaths of a project. Furthermore, those dependencies are propagated to dependent projects.
• provided
  This is much like compile, but indicates you expect the JDK or a container to provide the dependency at runtime. For example, when building a web application for the Java Enterprise Edition, you would set the dependency on the Servlet API and related Java EE APIs to scope provided because the web container provides those classes. This scope is only available on the compilation and test classpath, and is not transitive.
• runtime
  This scope indicates that the dependency is not required for compilation, but is for execution. It is in the runtime and test classpaths, but not the compile classpath.
• test
  This scope indicates that the dependency is not required for normal use of the application, and is only available for the test compilation and execution phases.
• system
  This scope is similar to provided except that you have to provide the JAR which contains it explicitly. The artifact is always available and is not looked up in a repository.
• import (only available in Maven 2.0.9 or later)
  This scope is only used on a dependency of type pom in the <dependencyManagement> section. It indicates that the specified POM should be replaced with the dependencies in that POM's <dependencyManagement> section. Since they are replaced, dependencies with a scope of import do not actually participate in limiting the transitivity of a dependency.

Each of the scopes (except for import) affects transitive dependencies in different ways, as is demonstrated in the table below. If a dependency is set to the scope in the left column, transitive dependencies of that dependency with the scope across the top row will result in a dependency in the main project with the scope listed at the intersection. If no scope is listed, it means the dependency will be omitted.

 compileprovidedruntimetestcompilecompile(*)-runtime-providedprovided-provided-runtimeruntime-runtime-testtest-test-

(*) Note: it is intended that this should be runtime scope instead, so that all compile dependencies must be explicitly listed - however, there is the case where the library you depend on extends a class from another library, forcing you to have available at compile time. For this reason, compile time dependencies remain as compile scope even when they are transitive.

===========================================================================================================

依赖范围

依赖范围用于限制依赖关系的传递性并影响到用于各种构建任务classpath，传递性表现在具体某个时间段具有依赖性，一共有三种时间段：在编译源代码时 、在编译测试代码及运行测试用例时、在运行时。

1、compile是默认的依赖范围，使用此依赖范围的Maven依赖，对于编译、测试、运行三种 classpath 都有效；

2、test只对于测试classpath 有效，测试classpath包括测试编译和测试运行；

3、provided对于编译和测试classpath有效，但在运行时无效；

4、runtime对于测试和运行classpath有效，但在编译主代码时无效；

5、system和 Provided 依赖范围完全一致，但是，使用 System 范围的依赖时必须通过 systemPath 元素显式地指定依赖文件的路径；

6、impor只用于<dependencyManagement>标签，它会引入其他POM的dependencyManagement的内容，并不参与到依赖传递。

依赖传递

假设a对b的依赖为第一依赖，b对c的依赖为第二依赖

1、表格下的英文可以理解为，a对b的依赖是指a依赖b的字节码文件，只要b是编译好的且b没有继承c中的某个类，则a在编译时不依赖c，如果b继承了c中的某个类，则a在编译时依赖c；

2、第二依赖为test的时候，第一依赖无论是什么都与b的测试代码没有关系，因此依赖不传递；

3、第二依赖为provided的时候，依赖不传递；

4、第二依赖为compile的时候，传递性依赖和第一依赖一样；

5、第二依赖为runtime的时候，除了第一依赖为compile时传递性依赖是runtime，传递性依赖和第一依赖一样；