Maven依赖配置
一个dependency的声明可以包含以下元素:
<dependencies>
<dependency>
<groupId>org.apache.kafka</groupId>
<artifactId>kafka-clients</artifactId>
<version>0.8.2.2</version>
<scope>compile</scope>
<optional>false</optional>
<exclusions>
<exclusion>
<groupId>org.apache.zookeeper</groupId>
<artifactId>zookeeper</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
- groupId+artifactId+version构成了依赖的基本坐标,Maven根据坐标才能找到依赖。
- scope定义了依赖的范围,默认是compile。
- optional定义了是否为可选依赖,默认是false。
- exclusion用来排除传递性依赖。
Maven依赖范围
Maven有以下几种依赖范围:
- compile:编译依赖范围,使用此依赖范围对于编译、测试、运行三种classpath都有效,即在编译、测试和运行时都要使用该依赖jar包;
- test:测试依赖范围,只对测试有效,表明只在测试的时候需要,在编译和运行时将无法使用该类依赖,如 junit;
- provided:已提供依赖范围。编译和测试有效,运行无效。如servlet-api,在项目运行时,tomcat等容器已经提供,无需Maven重复引入;
- runtime:运行时依赖范围。测试和运行有效,编译无效。如 jdbc 驱动实现,编译时只需接口,测试或运行时才需要具体的 jdbc 驱动实现;
- system:系统依赖范围,使用system范围的依赖时必须通过systemPath元素显示地指定依赖文件的路径,不依赖Maven仓库解析,所以可能会造成建构的不可移植,谨慎使用。
传递依赖
一个工程有一个compile依赖范围的spring-core依赖,而spring-core有一个compile依赖范围的commons-loggings依赖,则commons-loggings是本工程的传递性依赖。传递依赖就是scope标签,默认compile。
几种依赖范围的组合下,会有如下的依赖效果:
传递依赖原则
可选依赖
举例来说,一个类似hibernate的项目,它支持对mysql、oracle等各种数据库的支持,但是在引用这个项目时,我们可能只用到其对mysql的支持,此时就可以在这个项目中配置可选依赖。可选依赖就是optional标签,默认false。
<dependencies>
<dependency>
<groupId>sample.ProjectB</groupId>
<artifactId>Project-B</artifactId>
<version>1.0</version>
<scope>compile</scope>
<optional>true</optional>
</dependency>
</dependencies>
假设以上配置是项目A的配置,即:Project-A –> Project-B。在编译项目A时,是可以正常通过的。
如果有一个新的项目X依赖A,即:Project-X -> Project-A,此时项目X就不会依赖项目B了。如果项目X用到了涉及项目B的功能,那么就需要在X项目的pom.xml中重新配置对项目B的依赖。
排除依赖
Maven的传递性依赖会隐式地传入很多依赖,例如kafka-clients依赖了zookeeper,但我们想去除对zookeeper包的引用,那么就需要用exclusion元素了。见最上面的依赖配置。