9 Maven-继承和反应堆

1.Maven-简介 2.Maven-安装和配置 3.Maven-POM文件说明 4.Maven-坐标 5.Maven-依赖详解 6.Maven-仓库 7.Maven-生命周期和插件    8.Maven-聚合 9.Maven-继承和反应堆 10.Maven-使用NEXUS创建私服   11.Mavne-配置从NEXUS下载构件和为项目配置独立仓库   12.Maven-使用Hudson进行持续集成及系统配置  13.Maven-创建Hudson任务  14.Maven-Hudson监视任务、用户管理、工作目录

9.1 继承概念

抽取重复的配置，就是POM的继承。

1）该POM也十分简单，它使用了与其它模块一致的groupId和version。需要特别注意的是，它的packaging为pom，这一点与聚合模块一样，作为父模块的POM，其打包类型也必须为pom。

2）由于父模块知识为了帮助消除配置的重复，因此它本身不包含除POM之外的项目文件，也就不需要 src/main/java之类的文件夹了。
在子模块中的POM文件如下图：


分析：

1）上述POM中使用parent元素声明父模块，parent下的子元素groupId、artifactId和version指定了父模块的坐标，这三个元素是必须的。元素relativePath表示父模块POM的相对路径，上图中的../pom.xml表示父POM的位置在当前的上一层目录中。当项目构建时，Maven会首先根据relativePath检查父POM，如果找不到，再从本地仓库查找。relative的默认值是 ../pom.xml,也就是说，Maven默认父POM在上一层目录下。所以只要我们目录明确时，relativePath可以不写。

2）该子POM中发现没有声明groupId和version，不过这并不代表就没有groupId和version。实际上，父子模块隐式地从父模块继承了这两个元素，这也就消除了一些不必要的配置。

3）如果遇到子模块需要使用和父模块不一样的groupId或者version的情况，那么用户完全可以在子模块中显示声明。对于artifactId元素来说，子模块应该显式声明，一方面，如果完全继承groupId、artifactId和version，会造成坐标冲突；另一方面，即使使用不同的groupId或version，同样的artifactId容易造成混淆。

9.2 可继承的POM元素

出了groupId和version是可以被继承的，还有其他可继承的元素，如下：

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

9.3 依赖管理
Maven提供了一个dependencyManagement元素既能让子模块继承到父模块的依赖配置，有能保证子模块依赖使用的灵活性。在
dependencyManagement元素下的依赖声明不会引入实际的依赖，不过它能够约束dependencies下的依赖使用。如下图：

这里使用的dependencyManagement声明的依赖既不会给自己引入依赖，也不会给它的子模块引入依赖，不过这段配置是会被继承的。如下是子模块的编写方式：

分析：

1）上述的引用中只配置了groupId和artifactId，省去了version，而junit依赖不仅省去了version，还省去了依赖范围scope。

2）之所以可以省略是因为完整的依赖声明已经包含在父POM中，子模块只需要配置简单的groupId和artifactId就能获得对应的依赖信息，从而引入正确的依赖。

3）使用这种依赖管理机制似乎不能减少太多的POM配置，不过本屌还是强烈推荐采用这种用法。其主要原因在于父POM中使用dependencyManagement声明依赖能够统一项目范围中依赖的版本，当依赖版本在父POM中声明后，子模块再使用依赖的时候就无需声明版本，也就不会发生多个子模块使用依赖版本不一致的情况。这可以帮助降低依赖冲突的几率。

9.4 插件管理
既然有了dependencyManagement来管理依赖，肯定也有一个来管理插件，它就是pluginManagement。如下图：
图一：

图二：

第一个是父pom，第二个是子pom

pluginManagement和dependencyManagement的基本原理差不多，这里不再赘述。

9.5 聚合与继承的关系
1）对于聚合模块来说，它知道有哪些被聚合的模块，但那些那些被聚合的模块不知道这个聚合模块的存在。
2）对于继承关系的父POM来说，它不知道有哪些子模块继承于它，但那些子模块都必须知道自己的父POM是什么。
3）关系，聚合POM与继承关系中的父POM的packaging都必须是pom，同时，聚合模块与继承关系中的父模块除了pom之外都没有实际的类容。


9.6 反应堆
在一个多么快的Maven项目中，反应堆(Reactor)是指所有模块组成的一个构件结构。对于但模块的项目，反应堆就是该模块本身，但对于多模块项目来说，反应堆就包含了各模块之前继承与依赖的关系，从而能够自动计算出合力的模块构建顺序。

构建顺序：Maven按序读取 POM，如果该POM没有依赖模块，那么就构建该模块，否则就先构建其依赖模块，如果该依赖模块还依赖其他模块，则进一步先构建依赖的模块。