2019独角兽企业重金招聘Python工程师标准>>> 
摘要
继承和聚合看似都是在主要的POM文件中做一下相应的配置，在实际操作过程中往往只是知其然不知其所以然，不知道的可能很容易混淆。
1 继承
继承就是在从主pom那里继承许多重用的配置，可以省去许多代码量了。
使用继承方式的话，需要一个主POM，其packaging定义为pom。它本身可以不参与构建
<groupId>com.sd</groupId><artifactId>sd.excel</artifactId><packaging>pom</packaging><version>1.0-SNAPSHOT</version>此外还需要在子模块中 定义父模块的相关信息。
<parent><artifactId>sd.excel</artifactId><groupId>com.sd</groupId><version>1.0-SNAPSHOT</version><relativePath>../pom.xml</relativePath></parent><modelVersion>4.0.0</modelVersion><artifactId>sd.excel.base</artifactId><name>sd.excel.base</name>
在parent元素中声明的是父pom的GAV和父POM的相对路劲。 然后再声明自己的GAV。 上图的group和version省略了，原因是从主POM那里继承了。
除了groupId和Version 还有哪些元素可以被继承的呢？
1.1 可继承的POM元素
| groupId | 项目Id |
| version | 项目版本 |
| description | 项目描述 |
| organization | 项目组织信息 |
| inceptionYear | 项目创始年份 |
| url | 项目url地址 |
| developers | 项目开发者 |
| contributors | 项目贡献者 |
| distributionManagement | 项目部署配置 |
| issueManagement | 项目缺陷跟踪系统信息 |
| ciManagement | 项目的持续集成系统信息 |
| scm | 项目的版本控制系统信息 |
| mailingList | 项目的邮件列表信息 |
| properties | 自定义的maven属性 |
| dependencies | 项目的依赖配置 |
| dependenciesManagement | 项目的依赖配置管理 |
| repositories | 项目仓库配置 |
| build | 项目的构建配置，包括源码，输出目录，插件配置等 |
| reporting | 报告配置 |
2. 聚合
所谓聚合，其实就是多模块构建。面对较为复杂的项目，通常都会被分为很多相互依赖的模块，而这些模块是独立构建，maven为了应付这种类似的需求，设置了聚合方式。
使用聚合方式，需要组建一个主模块或者说聚合模块，它是用来管理组织那些小模块。这个聚合模块本身是不用构建的，
它只需要定义一个看似较为特殊的POM即可。
我们以模块 account-email和account-persist为例，我们为此组建了一个名为account-aggregator的聚合模块。聚合模块的POM长这样：
<modelVersion>4.0.0</modelVersion><groupId>com.sd</groupId><artifactId>sd.excel</artifactId><packaging>pom</packaging><version>1.0-SNAPSHOT</version><modules><module>sd-excel-api</module><module>sd-excel-base</module></modules>
其中需要注意的地方是packaing 被定义为POM，其次它额外声明了 modules 在这里面 添加了各个module的名字。
当然了，这只是建立在 主POM文件和 各模块是父子层级关系的时候，当然也可以是平行关系。见下图
左图是父子关系的层级图，右图是平行关系的层级图。如果说只用层级关系的时候主POM中的module需要做相应的变化、
还有一点需要注意的是，各个被聚合模块不知道其他聚合模块的存在，如果模块之间有依赖关系，需要在自己的POM文件声明GAV。
好在MAVEN会根据依赖关系，决定编译打包顺序。
3 DependencyManagement
DependencyManagement 内部声名的依赖包 本身不会被项目引入， 如果项目使用的依赖包(包括隐形依赖，引入的一些包) 会优先从DependencyManagement里面查询对应的版本号，如果没有则使用默认传递依赖的版本号。 用来解决maven冲突是个很好的办法
如：在dependencyManagement 中定义了junit的版本和scope
<dependencyManagement><dependencies><!-- Testing --><dependency><groupId>junit</groupId><artifactId>junit</artifactId><version>4.10</version><scope>test</scope></dependency></dependencies></dependencyManagement>那么在其他地方,在使用junit的时候可以不用定义 version和scope， 另外对于一些传递依赖导进来的junit 也会使用dependencyManagement中定义的版本和scope。
<dependencies><!-- Testing --><dependency><groupId>junit</groupId><artifactId>junit</artifactId></dependency><dependency><groupId>org.springframework</groupId><artifactId>spring-test</artifactId><version>4.3.8.RELEASE</version></dependency></dependencies>
