Maven聚合模块与继承和Maven的生命周期

因为Maven是提倡模块化编程的，所以会以多个工程分为多个模块。如果所有的功能、模块都写在一个工程里的话，不方便于扩展、升级、修改、查看和团队开发，而且也不方便于模块的复用。

Maven则是提倡将一个项目拆分成多个工程，每个工程完成一个模块或功能，这些工程就像零件一般，分别去进行开发，分为多个工程也方便于维护和分工合作。

每个工程模块可以通过pom配置文件实现串联，例如配置好pom文件之后，A工程可以直接对B工程的代码进行调用，C工程可以对A和B工程的代码进行调用。

因为工程拆分成了多个模块，即便能串联也无法进行一个统一的管理，如果某个模块缺少编译环境或者缺少某些依赖包就会出现整体的错误，所以我们需要一个单独的工程来管理这些模块，从而实现到统一管理，将这些散开的工程统一管理起来后就可以统一进行编译、测试或运行，这就是聚合模块。

按照Maven的聚合方式是把全部的工程都放在一个目录下，然后统一通过一个pom文件去管理，但是在Eclipse或者其他开发工具里要做到这一点比较麻烦，需要手动去操作。但是我们可以创建一个单独的pom工程去实现这个聚合管理：

创建完成，这个工程里就只有一个src的文件夹和pom文件：

然后编辑pom配置文件，进行模块映射：

因为只有到上一个目录才能看到其他的三个工程

然后就可以统一进行编译、测试或运行了：

Maven继承：

Maven的继承就是将父节点配置的依赖包继承下来，例如父节点配置了JUnit依赖包，这样的话只要继承它的工程都会自动下载此依赖包，就不需要自己再进行配置了。

这个父节点是一个pom工程，所以我们可以直接用管理工程做为父节点。

  示例：

  因为以上的做法会令所有继承此父节点的工程都下载此父节点配置的依赖包，但是如果某些工程并非必须需要此依赖包的话，就将此依赖包声明为无需自动下载依赖：

然后继承此父节点的工程就不会自动下载了：

如果有工程要配置此父节点配置的无需自动下载的依赖包，就写一个依赖即可，只不过不需要写此依赖包的版本号：

Maven的生命周期：

Maven强大的一个重要的原因是它有一个十分完善的生命周期模型(lifecycle)，这个生命周期可以从两方面来理解，第一，顾名思义，运行Maven的每个步骤都由它来定义的，这种预定义的默认行为使得我们使用Maven变得简单，相比而言，Ant的每个步骤都要你手工去定义。第二，这个模型是一种标准，在不同的项目中，使用Maven的接口是一样的，这样就不用去仔细理解每个项目的构建了，一般情况下，mvn clean install 这样的命令是通用的。我想，一定是吸收了许多项目的经验，Maven才能定义出如此完善的模型。

Maven有三套相互独立的生命周期，请注意这里说的是“三套”，而且“相互独立”，初学者容易将Maven的生命周期看成一个整体，其实不然。这三套生命周期分别是：

· Clean Lifecycle 在进行真正的构建之前进行一些清理工作。

· Default Lifecycle 构建的核心部分，编译，测试，打包，部署等等。

· Site Lifecycle 生成项目报告，站点，发布站点。

我再次强调一下它们是相互独立的，你可以仅仅调用clean来清理工作目录，仅仅调用site来生成站点。当然你也可以直接运行 mvn clean install site 运行所有这三套生命周期。

每套生命周期都由一组阶段(Phase)组成，我们平时在命令行输入的命令总会对应于一个特定的阶段。比如，运行mvn clean ，这个的clean是Clean生命周期的一个阶段。有点绕？要知道有Clean生命周期，也有clean阶段。Clean生命周期一共包含了三个阶段：

· pre-clean  执行一些需要在clean之前完成的工作

· clean  移除所有上一次构建生成的文件

· post-clean  执行一些需要在clean之后立刻完成的工作

分支图：

mvn clean 中的clean就是上面的clean，在一个生命周期中，运行某个阶段的时候，它之前的所有阶段都会被运行，也就是说，mvn clean 等同于 mvn pre-clean clean ，如果我们运行 mvn post-clean ，那么 pre-clean，clean 都会被运行。这是Maven很重要的一个规则，可以大大简化命令行的输入。

下面看一下Site生命周期的各个阶段：

· pre-site     执行一些需要在生成站点文档之前完成的工作

· site    生成项目的站点文档

· post-site     执行一些需要在生成站点文档之后完成的工作，并且为部署做准备

· site-deploy     将生成的站点文档部署到特定的服务器上

分支图：

这里经常用到的是site阶段和site-deploy阶段，用以生成和发布Maven站点，这可是Maven相当强大的功能，Manager比较喜欢，文档及统计数据自动生成，很好看。

  最后，来看一下Maven的最重要的Default生命周期，绝大部分工作都发生在这个生命周期中，这里，我只解释一些比较重要和常用的阶段：

记住，运行任何一个阶段的时候，它前面的所有阶段都会被运行，这也就是为什么我们运行mvn install 的时候，代码会被编译，测试，打包。

Maven插件：

Maven的核心分发包只有不到3MB的大小，Maven会在需要的时候下载并使用插件，对于插件本身，为了能够复用代码，它往往能够完成多个任务。Maven的生命周期与插件相互绑定，用以完成实际的构建任务。具体而言是生命周期的阶段与插件的目标相互绑定，以完成某个具体的构建任务。

一个插件通常可以完成多个任务，每一个任务就叫做插件的一个目标。如执行mvn install命令时，调用的插件和执行的插件目标如下：

Maven的生命周期是抽象的，实际需要插件来完成任务，这一过程是通过将插件的目标（goal）绑定到生命周期的具体阶段（phase）来完成的。如：将maven-compiler-plugin插件的compile目标绑定到default生命周期的compile阶段，完成项目的源代码编译：

内置的绑定：

        Maven对一些生命周期的阶段（phase）默认绑定了插件目标，因为不同的项目有jar、war、pom等不同的打包方式，因此对应的有不同的绑定关系，其中针对default生命周期的jar包打包方式的绑定关系如下：

第二列中，冒号后面即是绑定的插件目标，冒号前面是插件的前缀（prefix），是配置和使用插件的一种简化方式。Plugin Prefix。

 

自定义绑定：

  用户可以根据需要将任何插件目标绑定到任何生命周期的阶段，如：将maven-source-plugin的jar-no-fork目标绑定到default生命周期的package阶段，这样，以后在执行mvn package命令打包项目时，在package阶段之后会执行源代码打包，生成如：ehcache-core-2.5.0-sources.jar形式的源码包。

配置插件

        Maven插件高度易扩展，可以方便的进行自定义配置。如：配置maven-compiler-plugin插件编译源代码的JDK版本为1.7：

整体的语法规则：

本文转自 ZeroOne01 51CTO博客，原文链接：http://blog.51cto.com/zero01/1976990，如需转载请自行联系原作者