Maven聚合与继承-优快云博客

本文链接：https://blog.youkuaiyun.com/AprilSky_Zero/article/details/52027264

聚合;

<groupId>com.zc.book.account</groupId>

<artifactId>account-aggregator</artifactId>

<version>1.0.0-SNAPSHOT</version>

<name>Account Aggregator</name>

<module>account-email</module>

<module>account-persist</module>

</modules>

要聚合的pom文件account-email和account-persist。packaging的值必须为pom，name字段是为了给项目提供一个更容易阅读的名字。modules这是实现聚合最

核心的配置。用户可以通过在一个打包方式为pom的Maven项目中声明任意数量的module元素来实现模块的聚合，module的值都市一个当前pom的相对目录。

为了方便用户构建项目，通常将聚合模块放在项目目录的最顶层，其他模块则作为聚合模块的子目录存在，这样当用户得到源码的时候，第一眼发现的就是聚合模

块的POM不用从多个模块中去寻找聚合模块来构建项目：

account-aggregator

|——account-email

| |——pom.xml
|

|——account-persist

| |——pom.xml

pom.xml

如果使用平行目录结构，聚合模块的POM也需要做相应的修改，以指向正确的模块目录：

<module>../account-email</module>

<module>../account-persist</module>

</modules>

所谓的平行结构，如下

account-aggregator

|——pom.xml

account-email

|——pom.xml

account-persist

|——pom.xml

maven会首先解析聚合模块的POM、分析要构建的模块、并计算出一个反应堆构建顺序，然后根据这个顺序依次构建各个模块。反应堆是所有模块组成一个构建

结构。

继承：

通过聚合我们可以知道多个模块POM中存在大量的重复，在java中，我们可以使用类继承在一定程度上消除重复，在maven的世界中，也有类似的机制能让我们

抽取出重复的配置，这就是Pom的继承。

account-parent:

类似java我们需要创建POM的父子结构，然后再父POM中声明一些配置供子POM继承，以实现“一处声明，多处使用的目的”。我们在acount-aggregator下创建一

个名为account-parent的子目录，然后改子目录下建立一个所有除account-aggregator之外模块的父模块。

<groupId>com.zc.book.account</groupId>

<artifactId>account-parent</artifactId>

<version>1.0.0-SNAPSHOT</version>

<name>Account Parent</name>

</project>

该Pom使用了与其他模块一致的groupId和version，使用的artifactId为account-parent表示这是一个父模块。需要特别注意的是，他的packaging为pom，这一点

与聚合模块一样，作为覆膜款的POM，其打包类型也必须为pom。由于父模块只是为了帮助消除配置的重复，因此它本身不包含除POM之外的项目文件，也就不

需要src/main/java之类的文件夹了。

有了父模块就要有其他模块来继承。account-email的Pom修改如下

<groupId>com.zc.book.account</groupId>

<artifactId>account-parent</artifactId>

<version>1.0.0-SNAPSHOT</version>

<relativePath>../account-parent/pom.xml</relativePath>

</parent>

<artifactId>account-email</.artifactId>

<name>Account Email</name>

...

</dependenciese>

<build>

...

</plugins>

</build>

</project>

上述POM中使用parent元素声明父模块，parent下的子元素groupId、artifactId、version指定了父模块的坐标，这三个元素是必须的。元素relativePath表示父模块的

相对路径。正确设置relativePath非常重要。这个POM没有为account-email声明groupId和version，这个子模块是隐式地从父模块继承了这两个元素，消除了不必要

的配置。对于artifactId元素来说，子模块应该显示的声明，一方面，如果完全继承groupId、artifactId和version，会造成坐标冲突；另一方面，即使使用不同的groupId

或version，同样的artifactId容易造成混淆。

可继承的POM元素：

*groupId:项目组ID，项目坐标的核心元素。

*version：项目版本，项目坐标的核心元素。

*description：项目的描述信息

*organization：项目的组织信息

*inceptionYear：项目的创始年份

*url：项目的URL地址

*developers：项目的开发者信息

*contributors：项目的贡献者信息

*destributionManagement：项目的部署配置

*issueManagement：项目缺陷跟踪系统信息

*ciManagement：项目的持续集成系统信息。

*scm：项目的版本控制系统信息

*mailingLists：项目的邮件列表信息

*properties：maven的自定义属性

*dependencies：项目的依赖配置

*dependencyManagement：项目的依赖管理配置

*repositories：项目的仓库配置

*build：包括项目的源代码目录配置、输出目录配置、插件管理配置等

*reporting：包括项目的报告输出目录配置、报告插件配置等

依赖管理：

dependencyManagement元素技能让子模块继承到父模块的依赖配置，又能保证子模块的灵活性。在dependencyManagement元素下的依赖声明不会引入实际

的依赖，不过它能够约束dependencies下的依赖使用。例如，可以再account-parent中加入这样的dependencyManagement配置。在父模块pom中配置dependencyManagement元素，若里面包含dependencies，则在子模块中只需要配置相对应groupId和artifactId即可。如果子模块不声明依赖的使用，即使

该依赖已经在父POM的dependencyManagement中声明了，也不会产生任何实际的效果。

想要在另外一个模块中使用相同的dependencyManagement配置，除了复制配置或者继承这两种方式为，还可以使用import范围依赖将配置导入

<groupId>com.zc.book.account</groupId>

<artifactId>account-parent</artifactId>

<version>1.0.0-SNAPSHOT</version>

<scope>import</scope>

</denpendency>

</dependencies>

</dependencyManagement>

上述代码中依赖的type值为pom，import范围依赖由于其特殊性，一般都指向打包类型为pom的模块。如果有多个项目，他们使用的依赖版本都是一致的，则就

可以定义一个使用dependencyManagement专门管理依赖的pom，然后再各个项目中导入这些依赖管理配置。

插件管理：