maven 聚合和继承

聚合

为了能够使用一条命令就能构建多个模块，需要额外创建一个模块，然后通过该模块构建整个项目所有模块，该模块暂且称之为聚合模块。聚合模块本身作为一个maven项目，必须要有自己的pom，不过作为一个聚合项目，其pom又有特殊的地方

1.<project>根节点下的<packaging>节点，一般项目不申明默认打包为jar文件，对于聚合模块来说它的值必须是pom，否则无法构建

2.modules元素，用户通过在一个打包方式为pom的maven项目中声明任意数量的module元素来实现模块的聚合。这里每个module的值都是当前pom的相对目录

为了方便定位内容，模块所处目录应当与其artifactid一致，为了方便用户构建项目，通常将聚合模块放在项目目录最顶层，其他模块作为聚合模块的子目录存在。当然这些都不是一定的。

另外聚合模块的内容一般只有一个pom文件

继承

多模块项目还要一个什么问题呢，就是配置的重复。maven的继承机制就是针对这个问题，我们可以创建pom的父子结构，然后在父pom中声明一些配置供子pom继承，这些pom也有一些特点

1.父pom的packaging也必须是pom

2.子pom使用parent元素声明父模块，parent元素中的relativePath表示父pom的位置，当项目构建时，maven先根据该元素检查父pom，如果找不到再从本地仓库找，relativePath的默认值是../pom.xml，即maven默认父pom在上一层目录下。

3.父pom的某些配置子pom继承后可以不用再写比如父pom的version等

可依赖的元素包括：groupId、version、url、distrubutionManagement、properties、dependencies、dependencyManagement、repositories、build、reporting等等

依赖管理

可继承元素包括dependencies说明依赖是可以被继承的，因此是可以将依赖配置放到父模块，子模块就能移除相应的配置。这种做法是可行的，但是存在一些问题，不一定所有子模块都要这些依赖。

maven提供的dependencyManagement既能让子模块继承依赖配置又能保证子模块使用的灵活性。在该元素下的依赖声明不会引入实际依赖，不过能够约束dependencies下的依赖使用。

比如父pom中配置

<groupId>junit</groupId>

<artifactId>junit</artifactId>

</dependency>

</dependencyManagement>

子pom可以这样配置

<groupId>junit</groupId>

<artifactId>junit</artifactId>

</dependency>

</dependencies>

这里省去了子pom中版本和作用范围的配置，这种配置方式省不了很多配置，但是能起到统一项目范围中依赖版本的作用

有依赖管理当然也有插件管理，pluginManagement跟dependencyManagement作用相似

聚合和继承的关系

maven中聚合和继承其实是两个概念，首先它们目的不同，前者主要为了快速方便构建项目，后者主要为了消除重复配置

对于聚合模块，它知道有哪些被聚合模块，但是被聚合的模块不知道聚合模块存在

父pom，不知道有哪些子模块继承它，但子模块必须知道自己的父pom是什么

如果非要说他们的共同特性，就是聚合模块和父模块除了pom外都没有实际内容，而pom的packaging都必须是pom，而在实际项目中，经常是一个pom既是聚合pom也是父pom

maven提倡的是“约定优于配置”（Convention Over Configuration），使用约定而不是更灵活的配置的原因主要是为了大量减少配置。比如maven默认源码目录为src/main/java/等

反应堆（Reactor）是指所有模块组成的一个构建结构，对于单模块的项目，反应堆就是模块本身，但对于多模块项目来说，反应堆就包含了各模块之间继承与依赖的关系

添加：

依赖传递，举个例子

项目中依赖spring-core，点开spring-core的pom发现该构件依赖common-logging，则项目依赖common-logging。展开项目的maven-dependencies就能看到common-logging的包