Maven聚合和继承的详细解释

说到聚合与继承我们都非常熟悉，maven相同也具备这种设计原则。以下我们来看一下Maven的pom怎样进行聚合与继承的配置实现。

一、为什么要聚合？

随着技术的飞速发展和各类用户对软件的要求越来越高。软件本身也变得越来越复杂，然后软件设计人员開始採用各种方式进行开发，于是就有了我们的分层架构、分模块开发，来提高代码的清晰和重用。针对于这一特性，maven也给予了对应的配置。

情景分析一：

我们在开发过程中，创建了2个以上的模块，每一个模块都是一个独立的maven project，在開始的时候我们可以独立的编译和測试执行每一个模块，可是随着项目的不断变大和复杂化，我们期望可以使用简单的操作来完毕编译等工作。这时Maven给出了聚合的配置方式。

所谓聚合，顾名思义。就是把多个模块或项目聚合到一起。我们能够建立一个专门负责聚合工作的Maven project --- aggregator。

建立该project的时候。我们要注意下面几点：

1.该aggregator本身也做为一个Maven项目，它必须有自己的POM

2.它的打包方式必须为： packaging

3.引入了新的元素：modules---module

4.版本号：聚合模块的版本号和被聚合模块版本号一致

5.relative
path：每一个module的值都是一个当前POM的相对文件夹

6.文件夹名称：为了方便的高速定位内容。模块所处的文件夹应当与其artifactId一致(Maven约定而不是硬性要求)，总之。模块所处的文件夹必须和<module>模块所处的文件夹</module>相一致。

7.习惯约定：为了方便构建，通常将聚合模块放在项目文件夹层的最顶层，其他聚合模块作为子文件夹存在。这样当我们打开项目的时候。第一个看到的就是聚合模块的POM

8.聚合模块降低的内容：聚合模块的内容不过一个pom.xml文件，它不包括src/main/java、src/test/java等文件夹，由于它不过用来帮助其他模块构建的工具。本身并没有实质的内容。

9.聚合模块和子模块的文件夹：他们能够是父子类，也能够是平行结构，当然假设使用平行结构，那么聚合模块的POM也须要做出对应的更改。

二、为什么要继承？

做面向对象编程的人都会认为这是一个没意义的问题，是的，继承就是避免反复，maven的继承也是这样，它另一个优点就是让项目更加安全

情景分析二：我们在项目开发的过程中，可能多个模块独立开发。可是多个模块可能依赖同样的元素，比方说每一个模块都须要Junit，使用spring的时候，其核心jar也必须都被引入。在编译的时候，maven-compiler-plugin插件也要被引入

怎样配置继承：

1.说到继承肯定是一个父子结构，那么我们在aggregator中来创建一个parent
project

2.<packaging>: 作为父模块的POM，其打包类型也必须为POM

3.结构：父模块仅仅是为了帮助我们消除反复，所以它也不须要src/main/java、src/test/java等文件夹

4.新的元素：<parent>
， 它是被用在子模块中的

5.<parent>元素的属性：<relativePath>:
表示父模块POM的相对路径。在构建的时候。Maven会先依据relativePath检查父POM，假设找不到，再从本地仓库查找

6.relativePath的默认值：
../pom.xml

7.子模块省略groupId和version：
使用了继承的子模块中能够不声明groupId和version, 子模块将隐式的继承父模块的这两个元素

三、可被继承的POM元素

groupId:项目组ID,项目坐标的核心元素

version: 项目版本号, 项目坐标的核心元素

description: 项目的描写叙述信息

organization: 项目的组织信息

inceptionYear: 项目的创始年份

url: 项目的URL地址

developers: 项目开发人员信息

contributors: 项目的贡献者信息

distributionManagement: 项目的部署配置

issueManagement: 项目的缺陷跟踪系统信息

ciManagement: 项目的持续集成系统信息

scm: 项目的版本号控制系统信息

mailingLists: 项目的邮件列表信息

properties: 自己定义的maven属性

dependencies: 项目的依赖配置

dependencyManagement: 项目的依赖管理配置

repositories: 项目的仓库配置

build: 包含项目的源代码文件夹配置、输出文件夹配置、插件配置、插件管理配置等

reporting: 包含项目的报告输出文件夹配置、报告插件配置等

四、maven的依赖管理

我们知道dependencies是能够被继承的。这个时候我们就想到让我们的发生了共用的依赖元素转移到parent中。这样我们又进一步的优化了配置。但是问题也随之而来，假设有一天我创建了一个新的模块，但是这个模块不须要这些parent的依赖，这时候怎样处理？

是的，maven的依赖管理就是来解决问题的

添加一个新的元素：dependencyManagement

从上面的列表中我们发现dependencyManagement也是可以被继承的。这恰恰满足了我们的须要。它既可以让子模块继承到父模块的依赖配置，又能保证子模块依赖使用的灵活性

dependencyManagement的特性：在dependencyManagement中配置的元素既不会给parent引入依赖，也不会给它的子模块引入依赖，不过它的配置是可继承的

最佳实践：

这时候我们就能够在父POM中声明这些依赖：

<span style="white-space:pre">	</span><properties>
<target.version>2.5.6</target.version>
</properties>

<dependencyManagement>
<dependencies>
<dependency>
<groupId>your groupId</groupId>
<artifactId>your artifactId</artifactId>
<version>${target.version}</version>
</dependency>
</dependencies>
</dependencyManagement>

子模块的POM继承这些配置：子模块继承这些配置的时候，仍然要声明groupId和artifactId,表示当前配置是继承于父POM的，从而直接使用父POM的版本号相应的资源

<span style="white-space:pre">		</span><dependencies>
<dependency>
<groupId>your groupId</groupId>
<artifactId>your artifactId</artifactId>
</dependency>
</dependencies>

这个能够有效的避免多个子模块使用依赖版本号不一致的情况，有助于减少依赖冲突的几率。

注：仅仅有子模块配置了继承的元素。才会真正的有效，否则maven是不会载入父模块中声明的元素。

五、Maven的插件管理

再添加一个新的元素：<pluginManagement>

这个元素和<dependencyManagement>相类似。它是用来进行插件管理的。

在我们项目开发的过程中，也会频繁的引入插件，所以解决这些复杂配置的方法就是使用插件管理

我们能够在父POM中做例如以下声明：

<span style="white-space:pre">	</span><build>
<pluginManagement>
<plugins>
<plugin>
<groupId></groupId>
<artifactId></artifactId>
<version></version>
<executions>
<execution>
<id></id>
<goals>
<goal></goal>
</goals>
<phase></phase>
<configuration>
<source></source>
<target></target>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
</build>

在子模块中，我们能够直接继承

<span style="white-space:pre">	</span><build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
</plugin>
</plugins>

<pre name="code" class="html"><span style="white-space:pre">	</span></build>

我们会发现，继承的细节上和<dependencyManagement>差点儿一样。

六、聚合与继承的总结

当我们明确聚合与继承的细节之后，我们会发现：

对于聚合模块来说。它知道有哪些被聚合的模块，而对于被聚合的模块来说，它们不知道被谁聚合了，也不知道它的存在

对于继承关系的父POM来说，它不知道自己被哪些子模块继承了，对于子POM来说，它必须知道自己的父POM是谁

在一些最佳实践中我们会发现：一个POM既是聚合POM，又是父POM，这么做主要是为了方便。

用人之道：首用圣人，次用君子，宁用庸才，不用小人。

感悟——是这样，人常说真坏人并不可怕，可怕的是假好人（小人）。