Maven3-依赖

2018-02-06 本文已影响22人毛大黑

依赖配置

我们先来看一份简单的依赖声明：

<project>
...
<dependencies>
     <dependency>
         <groupId>...</groupId>
         <artifactId>...<artifactId>
         <version>...</version>
         <type>...</type>
         <scope>...</scope>
         <optional>...</optional>
         <exclusions>
              <exclusion>...<exclusion>
              ...
         </exclusions>
     </dependency>
     ...
</dependencies>
...
</project>

可以看到所有依赖都会被放置在dependencies标签中，在dependency中的所有标签都是依赖的配置

type:依赖的类型，默认值为jar
scope:依赖的范围
optional:标记依赖是否可选
exclusions:用来排除传递性依赖

配置1依赖范围， scope

classpath

classpath：classpath会告诉java执行环境，在哪些目录下可以找到您所要执行的Java程序所需要的类或包

Maven和classpath

在Maven中会使用三种classpath,分别是编译classpath,测试classpath和运行classpath,所以配置scope指定的依赖范围就是指依赖与classpath的关系。

Maven中的依赖范围

Maven包括以下几种依赖范围：

compile:编译依赖范围，默认为此范围，使用此依赖范围对编译，测试，运行三种classpath都有效
test: 测试依赖范围，只对测试classpath有效
provided:已提供依赖范围，对编译和测试classpath有效，编译和测试的时候需要该依赖，运行时，容器已提供，就不需要重复引入
runtime: 运行时依赖范围，对测试和运行classpath有效
system:系统依赖范围，依赖范围和provided一致，但使用时必须通过systemPath元素显示指定依赖文件的路径
import:导入依赖范围，不会对三种classpath产生实际的影响

配置2传递性依赖，optional与exclusions

什么是传递性依赖？

现在有一个项目，若我们没有使用Maven,那么就需要我们手动下载相关的依赖，而这些依赖在定义时，有的也会有它自己的依赖，假设项目有依赖A,A依赖又依赖于a,依赖A和依赖a的依赖范围都是compile,这时候就称依赖a是项目的传递性依赖。有了传递性依赖，使用一个依赖时就不用考虑他依赖了什么，也不用担心引入了多余的依赖，Maven会解析各个直接依赖的POM,将那些必要的简介依赖，以传递性依赖的形式引入到当前的项目中。

传递性依赖和依赖范围

依赖范围影响传递性依赖

依赖调节

现有两条传递性依赖，如下：

A->B->C->X(1.0) ,A->D->X(2.0)
A->B->Y(1.0), A->C->Y(2.0)

可以看到两条依赖中，在A的两条依赖路径上都有两个版本的X或Y,显然两个版本都被解析是不对的，会造成依赖重复，那么Maven会选择哪个呢？，根据以上两种情况，Maven制定了如下两种规则：

路径近者优先，也就是在第一条依赖中，会解析X(2.0)
路径长度相同时，第一声明者优先,第二条依赖中，会解析Y(1.0)

可选依赖 optional

可选依赖就是指：A->B,B->X(可选)，B->Y(可选)，如B是一个持久层隔离工具包，支持多种数据库，构建B时需要多种数据库的驱动程序，但在使用B时，只能选择一种数据库。在编写B的pom.xml时，要在依赖中添加<optional>true</optional>配置。
可选依赖不会被传递，只会对B产生影响，当A依赖于B时,需要在A中显式的声明所依赖的数据库

排除依赖exclusions

A->B->C
A依赖B,B依赖C,若这时我们不想使用B依赖deC,而想自己定义，可以使用exclusions配置

<project>
<groupId>com.xikunqu.project</groupId>
<artifactId>project-A</artifactId>
<version>1.0.0</version>
<dependencies>
<dependency>
     <groupId>com.xikunqu.project</groupId>
     <artifactId>project-B</artifactId>
     <version>1.0.0</version>
     <exclusions>
         <exclusion>
              <groupId>com.xikunqu.project</groupId>
              <artifactId>project-C</artifactId>
         </exclusion>
      </exclusions>
</dependency>
<dependency>
     <groupId>com.xikunqu.project</groupId>
     <artifactId>project-c</artifactId>
     <version>1.0.0</version>
     </dependency>
</dependencies>
</project>

最佳实践

归类依赖

当我们引入了一个项目的多个模块，这些模块的版本还是相同的时，我们可以进行如下定义：

<project>
...
<properties>
     <springframework.version>2.5.6</springframework.version>
</properties>
<dependencies>
     <dependency>
         <groupId>org.springframework</groupId>
         <artifactId>spring-core</artifactId>
         <version>${springframe.version}</version>
     </dependency>
     ...
</dependencies>
</project>

优化依赖

mvn dependency:list ，查看当前项目的已解析依赖
mvn dependency:tree,查看当前项目的依赖数
mvn dependency:analyze，帮助分析当前项目的依赖