第八章 聚合与继承

1.   为了能用一条命令来构建一个实际项目下的多个模块，而不是到两个模块目录下分别执行 mvn 命令， Maven 提供了聚合（或者称为多模块）的特性。我们可以额外建一个聚合用的模块，它仅有一个 pom.xml 文件，没有别的目录和文件。在它的 pom.xml 中 packaging 必须为 POM ，并且多了一个 <modules> 元素。在 <modules> 中每一个 <module> 声明一个实际项目中的一个模块。这里的值不是模块的 artifactId ，而是模块目录相对于当前 POM 所在目录的相对路径。一般会将聚合模块放在项目目录的最顶层，其他功能模块作为聚合模块的子目录存在，子目录取名与功能模块的 artifactId 一致。比如：

<groupId>com.juvenxu.mvnbook.account</groupId>  
  
<artifactId>account-aggregator</artifactId>  
  
<version>1.0.0-SNAPSHOT</version>  
  
<packaging>pom</packaging>  
  
<name>Account Aggregator</name>  
  
<modules>  
  
  <module>account-email</module>  
  
  <module>account-persist</module>  
  
</modules>

 

对应的目录结构为

 

 

2.   我们可以为项目的所有功能模块创建一个父模块，然后在父 POM 中声明一些配置供子 POM 继承，以实现“一处声明，多处使用的目的”。父模块只有一个 pom.xml 文件，没有别的目录和文件。 pom.xml 中的 packaging 值必须为 POM 。在子 POM 中需要声明父模块：

 

<parent>

  <groupId>com.juvenxu.mvnbook.account</groupId>

  <artifactId>account-parent</artifactId>

  <version>1.0.0-SNAPSHOT</version>

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

</parent> 

 

元素 relativePath 声明了父 POM 的相对路径，默认值是 ../pom.xml 。同样还需要把父模块也加入到聚合模块中。

 

3.   可继承的 POM 元素有：

1）  groupId

2）  version

3）  description ( 没有 artifactId 和 name)

4）  organization

5）  inceptionYear ( 项目创始年份 )

6）  url

7）  developers

8）  contributors

9）  distributionManagement

10）  issueManagement （项目的缺陷跟踪系统信息）

11）  ciManagement （项目的持续集成系统信息）

12）  scm （项目的版本控制系统的信息）

13）  mailingLists

14）  properties

15）  dependencies

16）  dependencyManagment

17）  repositories

18）  build （包括项目的源码目录、输出目录、插件配置、插件管理配置等）

19）  reporting （包括项目的报告输出目录配置、报告插件配置等）

 

4.   虽然 depedencies 是可以被继承的，但如果所有的子模块都必须继承父模块的所有 dependencies 显然是不合理的， Maven 在父 POM 中提供了 dependencyManagement 元素，能让子 POM 有选择地继承依赖。父模块的 dependencyManagement 元素中用 dependencies 元素声明的依赖，可以被子 POM 有选择地继承，方法是在子 POM 的 dependencies 元素中也声明该依赖，并且只需要声明 goupId 和 artifactId 即可，当然也可以声明别的属性来覆盖父 POM 中的声明。如果子模块不声明依赖的使用，那在 POM 中 dependencyManagement 中声明的依赖不会产生任何效果。

 

5.   import 范围的依赖只有在 dependencyManagement 中声明才有效果，使用该范围的依赖通常指向另一个 POM ，作用是将目标 POM 中的 dependencyManagement 配置导入并合并到当前 POM 的 dependencyManagement 配置中。如：

 

<dependencyManagement>

  <dependencies>

    <dependency>

    <groupId>com.juvenxu.mvnbook.account</groupId>

        <artifactId>account-parent</artifactId>

       <version>1.0-SNAPSHOT</version

      <type>pom</type>

      <scope>import</scope>

    </dependency>

  </dependencies>

</dependencyMangement> 

 

注意，上述代码中 type 值必须为 pom 。如果有多个实际项目，它们使用的依赖版本都是一致的，则可以定义一个专门管理共用依赖的 POM ，然后在各个实际项目中导入这个 POM 的 dependencyManagment 。

 

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

 

7.   当项目中的多个模块有同样的插件配置时，应当将配置移到父 POM 的 pluginManagement 元素中。即使各个模块对于同一插件的具体配置不尽相同，也应当使用父 POM 的 pluginManagement 元素统一声明插件的版本。这样可以统一项目使用的插件版本。

 

8.   一个 POM 可以既是聚合 POM ，又是父 POM 。我们一般为了方便可以这么做。（子 POM 中 relativePath 的默认值本就指向 ../pom.xml ）

 

9.   在使用 Maven 的过程中我们应该注意：约定优于配置。任何一个 Maven 项目都隐式地继承自超级 POM ，对于 Maven 3 而言，超级 POM 在 lib/maven-model-builder-x.x.x.jar 中的 org/apache/maven/model/pom-4.0.0.xml 下，对于 Maven 2 而言，超级 POM 在 lib/maven-x.x.x-uber.jar 中的 org/apache/maven/project/pom-4.0.0.xml 下。这里 x.x.x 表示 Maven 的具体版本号。

 

10.   在一个多模块的 Maven 项目中， Reactor 是指所有模块组成的一个构建结构。对于单模块的项目， Reactor 就是该模块本身。而对多模块项目来说， Reactor 就包含了各模块之间继承与依赖的关系，从而能够自动计算出合理的模块构建顺序。

 

11.   实际的多模块构建顺序是这样形成的： Maven 按序读取 POM （聚合模块本身就是第一个 POM ），如果该 POM 没有依赖模块，那么就构建该模块，否则就先构建其依赖模块，如果该依赖模块还依赖其他模块，则进一步构建依赖的依赖。

 

12.   Maven 命令提供如下选项，实时裁剪 Reactor ：

-am, --also-make 同时构建 -pl 参数中所列模块的依赖模块

-amd, --also-make-dependents 同时构建依赖于 -pl 参数中所列模块的模块

-pl, --projects <arg> 构建指定的模块，模块间用逗号分隔。

-rf, --resume-from <arg> 从 Reactor 中指定的模块开始构建，至 Reactor 结束。