写在前面:pom.xml是maven依赖配置选项的地方。
1、概念介绍
一、Dependencies:是可选依赖(Optional Dependencies)
二、Exclusions:是依赖排除(Dependency Exclusions)
三、dependencyManagement :统一多模块的依赖版本
每个依赖节点<dependency>都由三个子节点组成:
- <groupId> : 该依赖库所属的组织名称
- <artifactId> : 依赖的库名
- <version> : 依赖的库版本
在POM 4中,<dependency> 中还引入了<scope> ,它主要管理依赖的部署。目前<scope> 可以使用5个值:
- compile,缺省值,适用于所有阶段,会随着项目一起发布。
- provided,类似compile,期望JDK、容器或使用者会提供这个依赖。如servlet.jar。
- runtime,只在运行时使用,如JDBC驱动,适用运行和测试阶段。
- test,只在测试时使用,用于编译和运行测试代码。不会随项目发布。
- system,类似provided,需要显式提供包含依赖的jar,Maven不会在Repository中查找它。
2.使用方式及为什么这么用
一、Dependencies :
(1)当一个项目A依赖另一个项目B时,项目A可能很少一部分功能用到了项目B,此时就可以在A中配置对B的可选依赖。举例来说,一个类似hibernate的项目,它支持对mysql、oracle等各种数据库的支持,但是在引用这个项目时,我们可能只用到其对mysql的支持,此时就可以在这个项目中配置可选依赖。
(2)配置可选依赖的原因:
1)节约磁盘、内存等空间;
2)避免license许可问题;
3)避免类路径问题,等等。
(3)示例:
<project>
...
<dependencies>
<!-- declare the dependency to be set as optional -->
<dependency>
<groupId>sample.ProjectB</groupId>
<artifactId>Project-B</artifactId>
<version>1.0</version>
<scope>compile</scope>
<optional>true</optional> <!-- value will be true or false only -->
</dependency>
</dependencies>
</project>
假设以上配置是项目A的配置,即:Project-A –> Project-B。在编译项目A时,是可以正常通过的。如果有一个新的项目X依赖A,即:Project-X -> Project-A。此时项目X就不会依赖项目B了。如果项目X用到了涉及项目B的功能,那么就需要在pom.xml中重新配置对项目B的依赖。假设A->B, B->x(可选), B->y(可选)。这里由于x,y是可选依赖,依赖不会传递,x,y将不会对a有任何影响。
总结一句话:依赖不具有传递性,新项目使用某依赖时,需要重新引入。
二、Exclusions
(1)当一个项目A依赖项目B,而项目B同时依赖项目C,如果项目A中因为各种原因不想引用项目C,在配置项目B的依赖时,可以排除对C的依赖。
(2)示例(假设配置的是A的pom.xml,依赖关系为:A –> B; B –> C):
<project>
...
<dependencies>
<dependency>
<groupId>sample.ProjectB</groupId>
<artifactId>Project-B</artifactId>
<version>1.0</version>
<scope>compile</scope>
<exclusions>
<exclusion> <!-- declare the exclusion here -->
<groupId>sample.ProjectC</groupId>
<artifactId>Project-C</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
</project>
相对于dependencyManagement,父类中直接使用所有生命在dependencies里的依赖都会自动引入,并默认被所有的子项目继承。
如果依赖只在某个子项目中使用,则可以在子项目的pom.xml中直接引入,防止父pom的过于臃肿。
三、dependencyManagement
(1)为什么要用dependencyManagement?
如果你的项目有多个子模块,而且每个模块都需要引入依赖,但为了项目的正确运行,必须让所有的子项目(以下子项目即指子模块)使用依赖项的统一版本,才能保证测试的和发布的是相同的结果。那么如何保证模块之间的版本是一致的呢?
Maven 使用 dependencyManagement 来统一模块见的依赖版本问题。
在父项目的POM文件中,我们会使用到dependencyManagement元素。通过它来管理jar包的版本,让子项目中引用一个依赖而不用显示的列出版本号。Maven会沿着父子层次向上走,直到找到一个拥有dependencyManagement元素的项目,然后它就会使用在dependencyManagement元素中指定的版本号。
()示例
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.XXXX</groupId>
<artifactId>inf-B</artifactId>
<version>1.2.10</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
dependencies与dependencyManagement 区别总结:
1、dependencies即使在子项目中不写该依赖项,那么子项目仍然会从父项目中继承该依赖项(全部继承)
2、dependencyManagement里只是声明依赖,并不实现引入,因此子项目需要显示的声明需要用的依赖。如果不在子项目中声明依赖,是不会从父项目中继承下来的;只有在子项目中写了该依赖项,并且没有指定具体版本,才会从父项目中继承该项,并且version和scope都读取自父pom;另外如果子项目中指定了版本号,那么会使用子项目中指定的jar版本。
依赖的版本不能统一时,依赖传递的原则:
1、在工程的依赖树上,深度越浅,越被有限选择。
2、若两个依赖包处于依赖树上的同一层,则谁在前选择谁。
其他:
1.maven的依赖调解有两大原则:路径最近者优先;第一声明者优先。
2.maven的归类依赖,在pom文件中,我们经常会看到:
<dependency>
<groupId>org.scala-lang</groupId>
<artifactId>scala-library</artifactId>
<version>${scala.version}</version>
</dependency>
里面的${scala.version}是由下面语句统一配置:定义如下属性值后,maven会将pom中的所有的${scala.version}替换成实际值2.3.0
<properties>
<scala.version>2.3.0<scala.version>
</properties>
3.在修改完pom文件后,会重新加入依赖,对于一些需要提交的到机器上的作业而言,需要将其进行打包,即package,否则提交的作业还是依赖原来的包。比如在美团,有一个hadoop的中转站工具,名曰hope,在提交任务的时候,如果修改pom,则需要先进行hope package demo.hope然后再提交。
参考: