依赖配置
我们先来看一份简单的依赖声明:
<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,帮助分析当前项目的依赖
网友评论