maven的依赖机制

传递依赖关系（Transitive Dependencies）

依赖调解（Dependency mediation）

这个机制决定了当遇到多个版本作为依赖项时，将选择该 artifact 的哪个版本。maven 使用 最近定义（nearest definition）的机制，就是说，它在maven关系树中使用最接近项目的以来关系版本。可以通过在当前工程的 pom 文件中在确保某个依赖的版本。当在pom中指定了某个依赖的不同版本时，以先声明的依赖版本为准

（nearest definition）它在maven关系树中使用最接近项目的以来关系版本，考虑下面的依赖树

A
├── B
│   └── C
│       └── D 2.0
└── E
    └── D 1.0

定义了 A B C 三个模块，其中有两个依赖关系 A->B->C->D ,A->E->D,当构建 A时，使用的D是1.0 版本，因为 A-E-D这个依赖关系更短，如果要在构建A时强制使用D2.0版本，可以在A的依赖中明确指定 D2.0,依赖树如下图

A
 ├── B
 │   └── C
 │       └── D 2.0
 ├── E
 │   └── D 1.0
 │
 └── D 2.0 

依赖域（Dependency Scope）

• 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. A dependency with this scope is added to the classpath used for compilation and test, but not the runtime classpath. It is not transitive.
• runtime
  This scope indicates that the dependency is not required for compilation, but is for execution. Maven includes a dependency with this scope 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. This scope is not transitive. Typically this scope is used for test libraries such as JUnit and Mockito. It is also used for non-test libraries such as Apache Commons IO if those libraries are used in unit tests (src/test/java) but not in the model code (src/main/java).
• 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
  This scope is only supported on a dependency of type pom in the <dependencyManagement> section. It indicates the dependency is to be replaced with the effective list of dependencies in the specified 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.

在maven多模块项目中，为了保持模块间依赖的统一，常规做法是在parent model中，使用dependencyManagement预定义所有模块需要用到的dependency(依赖)

;)

<dependencyManagement>
        <dependencies>
            <!-- Feign是一种声明式、模板化的HTTP客户端:以HTTP接口的形式暴露自身服务 -->
            <dependency>
                <groupId>org.springframework.cloud</groupId>
                <artifactId>spring-cloud-starter-feign</artifactId>
                <version>${spring-cloud-starter-feign.version}</version>
            </dependency>
            <!-- 支持面向方面的编程即AOP，包括spring-aop和AspectJ -->
            <dependency>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-starter-aop</artifactId>
                <version>${spring.boot.version}</version>
            </dependency>
            <dependency>
                <groupId>org.aspectj</groupId>
                <artifactId>aspectjrt</artifactId>
                <version>${aspectjrt.version}</version>
            </dependency>
        </dependencies>
    </dependencyManagement>

;)

然后，子model根据实际需要引入parent中预定义的依赖

;)

<dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-aop</artifactId>
        </dependency>
    </dependencies>

;)

好处：

1、依赖统一管理(parent中定义，需要变动dependency版本，只要修改一处即可)；

2、代码简洁(子model只需要指定groupId、artifactId即可)

3、dependencyManagement只会影响现有依赖的配置，但不会引入依赖，即子model不会继承parent中dependencyManagement所有预定义的depandency，只引入需要的依赖即可，简单说就是“按需引入依赖”或者“按需继承”；因此，在parent中严禁直接使用depandencys预定义依赖，坏处是子model会自动继承depandencys中所有预定义依赖；

但是，问题也出现了：

单继承：maven的继承跟java一样，单继承，也就是说子model中只能出现一个parent标签；

parent模块中，dependencyManagement中预定义太多的依赖，造成pom文件过长，而且很乱；

如何让这些依赖可以分类并清晰的管理？

问题解决：import scope依赖

如何使用：

1、maven2.9以上版本

2、将dependency分类，每一类建立单独的pom文件

3、在需要使用到这些依赖的子model中，使用dependencyManagement管理依赖，并import scope依赖

3、注意：scope=import只能用在dependencyManagement里面,且仅用于type=pom的dependency

示例：

;)

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-dependencies</artifactId>
            <!-- 重要：版本号要和父模块中预定义的spring boot版本号保持一致 -->
            <version>${spring.boot.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

;)

maven编译后，下载了pom文件，在maven的本地仓库下查看pom文件如下：

好处分析：

1、单一职责原则，根据依赖的分类，细化每一个单一职责的pom文件

2、解决单继承问题，通过import pom文件达到依赖的目的（典型的非继承模式），从而不用从父类中引用依赖

3、父模块的pom就会非常干净，容易维护