Maven3-依赖

依赖配置

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

<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,将那些必要的简介依赖,以传递性依赖的形式引入到当前的项目中。

传递性依赖和依赖范围

依赖范围影响传递性依赖

依赖调节

现有两条传递性依赖,如下:

  1. A->B->C->X(1.0) ,A->D->X(2.0)
  2. 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,帮助分析当前项目的依赖
原文地址:https://www.cnblogs.com/quxikun/p/8420928.html