从0到0.1学习 maven(三：声明周期、插件、聚合与继承)
该文章为maven系列学习的第三篇，也是最后一篇
第一篇快速入口：从0到0.1学习 maven(一：概述及简单入门)
第二篇快速入口：从0到0.1学习 maven(二：坐标、依赖和仓库)
文章目录
- 啥子叫生命周期
- 生命周期详解
- clean生命周期
- default生命周期
- site生命周期
- 插件
- 插件配置
- 插件解析
- 聚合
- 继承
- 可继承的元素
- 依赖管理
- 插件管理
- 小结
- 反应堆
- 裁剪反应堆
啥子叫生命周期
构建步骤包括项目清理，初始化，编译，测试，打包，集成测试，验证，部署等等。maven将这些过程进行了抽象与统一，映射到了生命周期上。
可以将maven的生命周期理解成设计模式中的模板方法。父类定义整体结构，子类进行具体方法的实现和重写。在控制整体结构的同时也增加了可拓展性。maven没有对这些步骤提供实现，但是提供了默认绑定的插件，因此实际上每个步骤都是通过插件完成的。
生命周期详解
实际上，maven中的生命周期分成了三套，分别为clean，default与site，分别对应着 清理，构建与建立项目站点。每套生命周期都对应着一些有序的阶段。等下会详细介绍。三套生命周期本身是相互独立的，也就是调用clean不会影响到site。
clean生命周期
阶段1：pre-clean: 执行清理前需要完成的工作
阶段2：clean：清理上一次构建生成的文件
阶段3：post-clean：执行一些清理后需要完成的工作
阶段间是有序的，因此若想调用post-clean，会按preclean-clean-postclean的顺序执行。
default生命周期
在default周期中，定义了真正构建时需要的步骤。官方介绍可以参考：https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
- validate：验证项目是否正确，所有需要的信息是否都可用
- initialize：初始化例如属性的设置、 目录的创建等
- generate-sources：
- process-sources：处理项目主资源文件，一般是在src/main/resources中，完成变量替换等，再复制到项目输出的主classpath目录中。
- generate-resources
- proess-resources
- compile：编译源代码，一般是在src/main/java目录下
- process-classes
- generate-test-sources
- process-test-sources：处理测试资源文件。一般是在src/test/resources目录下，将该目录下的java文件编译输出到测试的classpath目录中。
- generate-test-resources
- process-test-resources
- test-compile：编译项目的测试代码。一般在src/test/java目录下。编译好后输出到测试的classpath目录中。
- process-test-classes
- test：用单元测试框架来测试编译后的源代码，测试代码不会打包或者部署。
- prepare-package
- package：用指定的后缀格式将编译后的代码进行打包
- pre-integration-test
- integration-test
- post-integration-test
- verify
- install：将package安装到本机的仓库中，以供其他依赖它的项目使用
- deploy：将最终的package复制到远程仓库中，以供其他开发者与项目共享
site生命周期
该周期的主要作用为建立和发布项目站点。根据pom中包含的信息，自动生成站点。
- pre-site：完成一些生成项目站点之前需要的工作
- site：生成项目站点文档
- post-site：完成一些生成项目站点之后的工作
- site-deploy：将生成的项目站点发布到服务器上。
插件
首先介绍一下插件目标，可以将一个小功能点理解成一个目标。前面提到核心功能都是通过插件的形式来实现的，但是针对一个功能点就开发一个插件显然会有很多冗余代码。因此一个插件可能会包含多个插件目标。
生命周期会与插件相互绑定，例如对于A过程， 插件B可以完成该任务，因此将AB进行绑定。如果某过程没有绑定插件，那该过程就不会有实际行为。
为了让用户几乎不用配置就可以构建maven项目，maven会对主要的生命周期阶段进行内置的插件绑定。
另外，一个插件也可以绑定多个阶段，例如clean生命周期的三个阶段都绑定在了maven-clean-plugin:clean插件上。
除了内置的绑定之外，用户也可以对阶段使用的插件进行自定义的绑定。
举一个自定义绑定插件的例子
<build><plugins><plugin><groupId>org.apache.maven.plugins</groupId><artifactId>maven-source-plugin</artifactId><version>2.2.1</version><executions><execution><id>attach-sources</id><phase>verify</phase><goals><goal>jar</goal></goals></execution></executions></plugin></plugins>
</build>
可以看到，在execution元素下，指定了phase（阶段）和goal（目标）。
尝试删除phase阶段，再次执行mvn verfify，执行依然成功。因为很多插件的目标在编写的时候已经默认绑定了阶段。可以通过mvn help:describe -Dplugin=xxxxx -Ddetail来查看具体信息
运行mvn help:describe -Dplugin=org.apache.maven.plugins:maven-source-plugin:2.2.1 -Ddetail看一下我们刚刚用的包的细节。
第五行：Bound to phase: package 指明了他绑定的默认生命周期阶段时package。
ps: 如果不加版本号，则自动获取最新的版本。加了detail是为了更详细的信息。如果仅仅想知道某个目标的信息，可以使用goal参数。
插件配置
命令行配置
maven沿用了java的命令行传参模式即“-D”
例如上述例子中 -Dplugin=xxx就表示着传递 名为plugin，值为xxx的参数。
POM中插件全局配置
对于很少或不会改变的参数，直接写死在pom文件中。
直接在version下面加一个configuration的子标签
<configuration><source>1.5</source><target>1.5</target>
</configuration>
POM中配置任务参数
还可以为某个插件任务配置特定的参数
<configuration><tasks><echo>I am a task</echo></tasks>
</configuration>
插件解析
首先，需要了解一个插件前缀的概念。我们刚刚使用了mvn help:describe"实际上是maven-help-plugin插件的describe目标。这里help就是插件前缀，其结构是groupId：artifactId。复习一下，依赖仓库的路径groupId/artifactId/maven-metadata.xml，插件仓库的元数据是在groupId/maven-metadata.xml下的。
插件像构件一样，以坐标的形式存储在maven仓库中。
插件仓库的子元素配置和依赖仓库完全相同。
<repositories><repository><id>central</id><name>Central Repository</name><url>https://repo.maven.apache.org/maven2</url><layout>default</layout><snapshots><enabled>false</enabled></snapshots></repository></repositories>
如果是maven的官方插件（groupId=org.apache.maven.plugins），则可以省略groupId配置。
对于核心插件，maven为它们在超级pom（所有maven项目的父pom）中预先设定了版本。因此核心插件可以不用指定版本。
对于非核心插件，类似于仓库的版本解析，插件也有元数据文件。maven遍历本地与远程插件仓库，找到lastest和release。maven2会使用latest，maven3会使用release。
聚合
实际项目中，可能是会由多个项目组合起来的，需要对每个项目进行打包构建。如果每次都一个一个地去模块对应的目录下构建那是相当麻烦。因此聚合，也叫多模块 就是在一个目录可以构建项目中的所有包。
首先需要创建出一个额外的模块，并写pom文件
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"><modelVersion>4.0.0</modelVersion><groupId>com.company.sc</groupId><artifactId>demo</artifactId><version>1.0.0-SNAPSHOT</version><packaging>pom</packaging><name>a_practise_demo</name><description>用于练习聚合的项目</description><modules><module>module_name_1</module><module>module_name_2</module><module>module-name-3</module></modules>
</project>
它与普通的模块有三处不同
- packaging的值为pom，这标志着该模块为聚合模块。对其需要打包的子模块，都遵照各模块的packaging类型。
- 多了一层modules，标记着该聚合模块包含哪些模块。值得注意的是这里module子标签实际上不是真正的模块名，而是模块的目录名。因此如果这个聚合模块不是其他模块的父文件夹的话，需要将module元素的内容改成能指向正确模块的目录。
- 实际上，该聚合模块只会包含一个pom.xml文件，不会有test或java目录和代码。它仅仅是帮助构建的工具，并没有实际的内容。
继承
在maven世界里也有继承这个概念。像聚合一样，需要单独抽出一个目录，编写父pom以完成“一处声明，多处使用”的目的。
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"><modelVersion>4.0.0</modelVersion><groupId>com.company.sc</groupId><artifactId>demo-parent</artifactId><version>1.0.0-SNAPSHOT</version><packaging>pom</packaging><name>a_practise_demo</name>
</project>
它与聚合有两点相同：
- 除了pom之外没有其他目录
- packaging使用的也是pom
继承父类的子模块需要加入如下内容
<parent><groupId>com.company.sc</groupId><artifactId>demo-parent</artifactId><version>1.0.0-SNAPSHOT</version><relativePath>../dir1/dir2/pom.xml</relativePath>
</parent>
groupId, artifactId, version 是定义坐标系的三个最基本的元素，是必须的。relativePath表示父pom的相对路径，默认值是…/pom.xml，也就是maven默认父pom在上一层目录下。
另外，如果有聚合模块的话，该继承模块也需要被添加到modules标签下。
可继承的元素
- groupId
- version
- description
- organization
- inceptionYear：项目的创建年份
- url：项目的url地址
- developers
- contributors
- distributionManagement：项目的部署配置
- issueManagement：项目的issue信息
- ciManagement：项目的持续集成系统信息
- scm：项目的版本控制系统信息
- mailingLists
- properties：自定义maven属性
- dependencies：项目的依赖配置
- dependencymanagement：项目的依赖管理配置
- repositories：项目的仓库配置
- build：包括项目的源码目录配置、输出目录配置、插件配置等
- reporting：包括项目的报告输出目录配置，报告插件配置等
依赖管理
父类的依赖可以被子类继承，但不一定所有的父类依赖都会被每个子类使用。这里maven提供了dependencyManagement元素，能让子模块继承到父模块的依赖配置，又能保证灵活性。因为dm元素下的依赖声明不会引入实际的依赖，但却能控制依赖。比如可以在父pom中声明依赖的groupId, artifactId, version，scope，子模块中就只需要groupId, artifactId，其他都可以从父类中继承。
依赖范围import只在dependencyManagement中才有效果。它的作用是将某pom中dm标签下的配置导入并合并到当前pom的dm元素中。假设另外一个模块想要导入我们前面的父类pom，可以通过以下配置。
<dependencyManagement><dependencies><dependency><groupId>com.company.sc</groupId><artifactId>demo-parent</artifactId><version>1.0.0-SNAPSHOT</version><type>pom</type><scope>import</scope></dependency></dependencies>
</dependencyManagement>
一般import都会指向打包类型为pom的模块，因此type元素的值为pom。
插件管理
类似于刚刚的依赖管理，插件相应地也可以使用pluginManagement进行管理：在父pom中配置plugin元素，当子pom中继承并配置了对应地groupId和artifactId，pm中的配置才会生效。
小结
对于聚合模块，它知道有哪些被聚合的模块，但是被聚合的模块不知道它。对于继承模块，继承该模块的子模块知道他，但是他不知道都有谁继承了他。两个关系刚好相反，但是配置的时候packaging都必须是pom。在实际项目中，一个pom可能又当聚合pom又当父pom。
反应堆
反应堆指的是所有的模块形成的一个构建结构。拿以下模块为例子，该部分从demo的pom中提取。
<modules><module>module_name_child_1</module><module>module_name_father</module><module>module_name_no_father</module>
</modules>
反应堆的构建顺序与声明顺序不一定一致，这个要取决于聚合与依赖关系。实际的构建顺序应为
demo->module_name_father->module_name_child_1->module_name_no_father
demo是聚合模块的起点，肯定是第一个构建的，然后按照顺序读取到了module_name_child_1，检查到它依赖着module_name_father，于是先去构建module_name_father。构建好了之后再构建module_name_father。接着继续按顺序，构建到module_name_no_father。一般来讲，依赖关系会将反应堆构建为有向无环图，如果有环，在构建时maven就会报错。
裁剪反应堆
如果想构建反应堆中的某些模块，可以使用mvn -h
- -am （–also-make）同时构建所列模块的依赖模块
- -amd（-also-make-dependens）同时构建 依赖于所列模块的模块
- -pl（–projects ）<args> 构建指定的模块，用逗号做分隔符
- -rf（-resume-from）<args> 从指定的模块构建反应堆
举个例子，假设a依赖于b和c，如果用-am a的话，就会同时构建a b c。如果用-amd b的话，就会构建 a b。假设之前的构建顺序是 a b c d，那-rf c 就会构建c和d