聚合与继承的关系
聚合是为了方便快速构建项目，继承是为了消除重复配置
共同点是两者的packaging都是pom，聚合模块与继承关系中的父模块除了pom之外都没有实际内容。
聚合关系与继承关系的比较：
在现有实际项目中，往往发现一个pom既是聚合pom又是父pom，这么做主要是为了方便。一般来说，融合使用聚合和继承没有什么问题。例如，可以将account-aggregator和account-parent合并成为一个新的account-parent，如下：
<modelVersion>4.0.0</modelVersion>
<groupId>com.juvenxu.mvnbook.account</groupId>
<artifactId>account-parent</artifactId>
<version>1.0.0-SNAPSHOT</version>
<packaging>pom</packaging>
<name>Account Parent</name>
<modules>
<module>account-email<module>
<module>account-persist</module>
</modules>
<properties>
<springframework.version>2.5.6</springframework.version>
<junit.version>4.7</junit.version>
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>${springframework.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
<version>${springframework.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>${springframework.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context-support</artifactId>
<version>${springframework.version}</version>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>${junit.version}</version>
<scope>test</scope>
</dependency>
</dependencies>
</dependencyManagement>
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.5</source>
<target>1.5</target>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<configuration>
<encoding>UTF-8</encoding>
</configuration>
</plugins>
</pluginManagement>
</build>相应的account-email和account-persist的pom配置也要做微小的修改。本来account-parent和他们位于同级目录，因此需要使用值为../account-parent/pom.xml的relativePath元素。现在新的account-parent在上一层目录，这是Maven默认能识别的父模块位置，因此不再需要配置relativePath,如下：
<parent>
<groupId>com.juvenxu.mvnbook.account</groupId>
<artifactId>account-parent</artifactId>
<version>1.0.0-SNAPSHOT</version>
</parent>
<artifactId>account-email</artifactId>
<name>Account Email</name>约定优于配置
Java成功的重要原因之一就是他能够屏蔽大部分操作系统的差异，XML流行的原因之一是所有语言都接受他。Maven提倡约定优于配置，这是Maven最核心的设计理念之一。
使用约定可以大量减少配置，先看一个简单的Ant配置文件：
<project name="my-project" default="dist" basedir=".">
<description>
simple example build file
</dedication>
<!-- 设置构建的全局属性 -->
<property name="src" location="src/main/java" />
<property name="build" location="target/classes" />
<property name="dist" location="target" />
<target name="init" >
<!-- 创建时间戳 -->
<tstamp/>
<!-- 创建编译使用的构建目录 -->
<mkdir dir="${build}" />
</target>
<target name="compile" depends="init" description="compile the source" >
<!-- 将Java代码从目录${src}编译至${build} -->
<javac srcdir="${src}" destdir="${build}" />
</target>
<target name="dist" depends="compile" description="generate the distribution">
<!-- 创建分发目录 -->
<mkdir dir="${dist}/lib/" />
<!-- 将${build}目录的所有内容打包至MyProject-${DSTAMP}.jar file -->
<jar jarfile="${dist}/lib/MyProject-${DSTAMP}.jar" basedir="${build}" />
</target>
<target name="clean" description="clean up" >
<!-- 删除${bulid}和${dist}目录树 -->
<delete dir="${build}" />
<delete dir="${dist}" />
</target>
</project>这段代码做的事情就是清除构建目录、创建目录，编译代码、复制依赖至目标目录、最后打包，做同样的使用Maven需要什么配置呢？maven只需要一个最简单的pom，如下：
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.juvenxu.mvnbook</groupId>
<artifactId>my-project</artifactId>
<version>1.0</version>
</project>但是为了获得这样简洁的配置，用户是需要付出一定的代价的，那就是遵循Maven的约定，Maven会假设用户的项目是这样的：
编译输出目录为：target/classes
打包方式为：jar
包输出目录为：target/
当然你也可以自己定义，个性往往意味着牺牲通用性，意味着增加无谓的复杂度，例如：Maven允许你自定义源码目录
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.juvenxu.mvnbook</groupId>
<artifactId>my-project</artifactId>
<version>1.0</version>
<build>
<sourceDirectory>src/java</sourceDirectory>
</build>
</project>该例中源码目录变成了src/java而不是默认的src/main/java，这就很容易出现问题了。
反应堆
在一个多模块的Maven项目中，反应堆（Reactor）是指所有模块组成的一个构建结构。对于单模块的项目，反应堆就是该模块本身，但对于多模块项目来说，反应堆就包含了各模块之间继承与依赖的关系，从而能够自动计算出合理的模块构建顺序。
首先我们来看下反应堆的构建顺序
以account-aggregator为例：
<modules>
<module>account-email</module>
<module>account-persist</module>
<module>account-parent</module>
</modules>该例中，account-aggregator没有依赖模块，因此先构建他，接着account-email，他依赖于account-parent模块，必须先构建account-parent，然后在构建account-email，最后到account-persist的时候由于其依赖的模块已经构建，因此直接构建。
裁剪反应堆
一般来说用户会选择构建整个项目或者选择构建单个模块，但是有些时候，用户会想要构建完整的反应堆中的某些模块。换句话说用户需要实时的裁剪反应堆，输入mvn -h可以看到
-am –also - make 同时构建所列模块的依赖模块 mvn clean install -pl account-email -am,account-email依赖于account-parent所以：
account parent
account eamil
-amd –also make dependents 同时构建依赖于所列模块的模块
mvn clean install -pl account-parent -amd，account-email和account-persist都依赖于account-parent所以：
account parent
account email
account persist
-pl –projects 构建指定的模块，模块之间用逗号分隔，例如：mvn clean install -pl account-email,account-persist
account eamil
account persist
-rf –resume-from 从指定的模块回复反应堆
mvn clean install -rf account-email，完整的反应堆构建顺序中，account-email第三，他之后只有account-persist
account email
account persist
在-pl -am或者-pl -amd的基础上还能应用-rf
mvn clean install -pl account-parent -amd -rf account-email
该命令中-pl和-amd参数会裁剪出一个account-parent,account-email,account-persist，在此基础上-rf从account-email构建
account email
account persist