Maven之聚合与继承

1.聚合
 

<project>
<modelVersion>4.0.0</modelVersion>
<groupId></groupId>
<artifactId></artifactId>
<version></version>
<packaging>pom</packaging>
<name></name>
<modules>
<module></module>
<module></module>
</modules>
</project>

对于聚合模块来说,其打包方式packaging的值必须为pom,否则就无法构建。POM的name字段是为了给项目提供一个更容易阅读的名字。之后是元素modules,这是实现聚合的最核心的配置。用户可以通过在一个打包方式为pom的Maven项目中声明任意数量的module元素来实现模块的聚合。这里每个module的值都是一个当前POM的相对目录。
一般来说,为了方便快速定位内容,模块所处的目录名称应当与其artifactId一致,不过这不是Maven的要求,用户也可以将account-email项目放到email-account/目录下。这时,聚合的配置就需要相应地改成<module>email-account</module>。

2.继承

<project>
<modelVersion>4.0.0</modelVersion>
<groupId></groupId>
<artifactId>parent</artifactId>
<version></version>
<packaging>pom</packaging>
<name></name>
</project>

<project>
<parent>
<groupId></groupId>
<artifactId></artifactId>
<version></version>
<relativePath>parent/pom.xml</relativePath>
</parent>
<modelVersion>4.0.0</modelVersion>
<groupId></groupId>
<artifactId>child</artifactId>
<version></version>
<packaging>pom</packaging>
<name></name>
</project>

该POM十分简单,它使用了与其他模块一致的groupId和version,使用的artifactId为account-parent表示这是一个父模块。需要特别注意的是,它的packaging为pom,这一点与聚合模块一样,作为父模块的POM,其打包类型也必须为pom。
由于父模块只是为了帮助消除配置的重复,因此它本身不包含除POM之外的项目文件,也就不需要src/main/java/之类的文件夹了。有了父模块,就需要让其他模块来继承它。
上述POM中使用parent元素声明父模块,parent下的子元素groupId、artifactId和version指定了父模块的坐标,这三个元素是必须的。元素relativePath表示父模块POM的相对路径,当项目构建时,Maven会首先根据relativePath检查父POM,如果找不到,再从本地仓库查找。relativePath的默认值是../pom.xml,也就是说,Maven默认父POM在上一层目录下。
正确设置relativePath非常重要。考虑这样一个情况,开发团队的新成员从源码库签出一个包含父子模块关系的Maven项目。由于只关心其中的某一个子模块,它就直接到该模块的目录下执行构建,这个时候,父模块是没有被安装到本地仓库的,因此如果子模块没有设置正确的relativePath,Maven将无法找到父POM,这将直接导致构建失败。如果Maven能够根据relativePath找到父POM,它就不需要再去检查本地仓库。

3.可继承的POM元素
groupId：项目组ID,项目坐标的核心元素。
version：项目版本,项目坐标的核心元素。
description：项目的描述信息。
organization：项目的组织信息。
inceptionYear：项目的创始年份。
url：项目的URL地址。
developers：项目的开发者信息。
contributors：项目的贡献者信息。
distributionManagement：项目的部署配置。
issueManagement：项目的缺陷跟踪系统信息。
ciManagement：项目的持续集成系统信息。
scm：项目的版本控制系统信息。
mailingLists：项目的邮件列表信息。
properties：自定义的Maven属性。
dependencies：项目的依赖配置。
dependencyManagement：项目的依赖管理配置。
repositories：项目的仓库配置。
build：包括项目的源码目录配置、输出目录配置、插件配置、插件管理配置等。
reporting：包括项目的报告输出目录配置、报告插件配置等。

4.依赖管理
Maven提供的dependencyManagement元素既能让子模块继承到父模块的依赖配置,又能保证子模块依赖使用的灵活性。在dependencyManagement元素下的依赖声明不会引入实际的依赖,不过它能够约束dependencies下的依赖使用。

<project>
<modelVersion>4.0.0</modelVersion>
<groupId></groupId>
<artifactId>parent</artifactId>
<version></version>
<packaging>pom</packaging>
<name></name>
<dependencyManagement>
<dependencies>
<dependency>
<groupId></groupId><artifactId></artifactId><version></version>
</dependency>
...
</dependencies>
</dependencyManagement>
</project>

<project>
<parent>
<groupId></groupId>
<artifactId></artifactId>
<version></version>
<relativePath>parent/pom.xml</relativePath>
</parent>
<modelVersion>4.0.0</modelVersion>
<groupId></groupId>
<artifactId>child</artifactId>
<version></version>
<packaging>pom</packaging>
<name></name>
<dependencies>
<dependency>
<groupId></groupId><artifactId></artifactId>
</dependency>
...
</dependencies>
</project>

上述POM中,所有的springframework依赖只配置了groupId和artifactId,省去了version,而junit依赖不仅省去了version,还省去了依赖范围scope。这些信息可以省略是因为子模块继承了父模块中的dependencyManagement配置,完整的依赖声明已经包含在父POM中,子模块只需要配置简单的groupId和artifactId就能获得对应的依赖信息,从而引入正确的依赖。
使用这种依赖管理机制似乎不能减少太多的POM配置,不过笔者还是强烈推荐采用这种方法。其主要原因在于在父POM中使用dependencyManagement声明依赖能够统一项目范围中依赖的版本,当依赖版本在父POM中声明之后,子模块在使用依赖的时候就无须声明版本,也就不会发生多个子模块使用依赖版本不一致的情况。这可以帮助降低依赖冲突的几率。
如果子模块不声明依赖的使用,即使该依赖已经在父POM的dependencyManagement中声明了,也不会产生任何实际的效果

5.scope:import依赖范围
 

<dependencyManagement>
<dependencies>
<dependency>
<groupId></groupId>
<artifactId>parent</artifactId>
<version></version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>

使用该范围的依赖通常指向一个POM,作用是将目标POM中的dependencyManagement配置导入并合并到当前POM的dependencyManagement元素中。例如想要在另外一个模块中使用与代码清单8-14完全一样的dependencyManagement配置,除了复制配置或者继承这两种方式之外,还可以使用import范围依赖将这一配置导入。
注意,上述代码中依赖的type值为pom,import范围依赖由于其特殊性,一般都是指向打包类型为pom的模块。如果有多个项目,它们使用的依赖版本都是一致的,则就可以定义一个使用dependencyManagement专门管理依赖的POM,然后在各个项目中导入这些依赖管理配置。

6.插件管理
Maven提供了dependencyManagement元素帮助管理依赖,类似地,Maven也提供了pluginManagement元素帮助管理插件。在该元素中配置的依赖不会造成实际的插件调用行为,当POM中配置了真正的plugin元素,并且其groupId和artifactId与pluginManagement中配置的插件匹配时,pluginManagement的配置才会影响实际的插件行为。