Maven 插件机制
Maven 的核心仅仅定义了抽象的生命周期，具体的任务是交由插件完成的，插件以独立的构
件形式存在，所以 Maven 核心的分发包只有不到 3MB，Maven 会在需要的时候下载并使用插件。
1. 插件目标（plugin goal）
对于插件本身，为了能够复用代码，它往往能够完成多个任务，
为每个这样的功能编写一个独立的插件显然是不可取的，因为这些任务背后都有很多可以复用的代码，
这些功能都聚集在一个插件里，每个功能就是一个插件目标。
a） 通用写法
冒号前面是插件前缀，冒号后面是该插件的目标。
例如：dependency:list、compiler:compile。
2. 插件绑定
Maven 的生命周期与插件相互绑定，用以完成实际的构建任务。更具体而言，
是生命周期的阶段与插件的目标相互绑定，以完成某个具体的构建任务。
例如：项目编译这一任务，对应了 default 生命周期的 compile 这一阶段。
a） 内置绑定
为了让用户几乎不用任何配置就能构建 Maven 项目，Maven 在核心为一些主要的生命周期阶段，
绑定了很多插件的目标，当用户通过命令行调用生命周期阶段的时候，
对应的插件目标就会执行相应的任务。
例如：clean 生命周期仅有 pre-clean、clean、post-clean 三个阶段。其中 clean与
maven-plugin:clean 绑定。maven-clean-plugin 仅有 clean 这一个目标，
其作用就是删除项目的输出目录。
i. clean 生命周期阶段与插件目标的绑定关系
| 生命周期阶段 |
插件目标 |
| pre-clean |
|
| clean |
maven-clean-plugin:clean |
| post-clean |
|
ii. site 生命周期阶段与插件目标的绑定关系
| 生命周期阶段 |
插件目标 |
| pre-site |
|
| site |
maven-site-plugin:site |
| post-site |
|
| site-deploy |
maven-site-plugin:deploy |
iii. default 生命周期阶段与插件目标的绑定关系
相比 clean 和 site 生命周期来说，default 生命周期与插件目标的绑定关系就显得复杂一些。
由于项目的打包类型会影响构建的具体过程，因此，default生命周期阶段与插件目标的绑定关系，
由项目打包类型决定。例如：最常见的 jar 类型生命周期的内置插件绑定关系
| 生命周期阶段 |
插件目标 |
执行任务 |
| process-resources |
maven-resources-plugin:resources |
复制主资源文件至主输出目录 |
| compile |
maven-compiler-plugin:compile |
编译主代码至主输出目录 |
| process-test-resources |
maven-resources-plugin:testResources |
复制测试资源文件至测试输出目录 |
| test-compile |
maven-compiler-plugin:testCompile |
编译测试代码至测试输出目录 |
| test |
maven-surefire-plugin:test |
执行测试用例 |
| package |
maven-jar-plugin:jar |
创建项目jar包 |
| install |
maven-install-plugin:install |
将项目输出构件安装到本地仓库 |
| deploy |
maven-deploy-plugin:deploy |
将项目输出构件部署到远程仓库 |
上表只列出了拥有插件绑定关系的阶段，default 生命周期还有很多其他阶段，
默认他们没有绑定任何插件，因此也没有任何实际行为。除了默认的 jar 类型外，
还有 war、pom、maven-plugin、ear 等。它们的default 生命周期与插件目标的绑定关系，
可参阅 Maven 官方文档：http://maven.apache.org/guides/introduction/introduction-to-the-
lifecycle.html#Built-in_Lifecycle_Bind-ings。
iv. 观察输出过程
执行 mvn clean install 命令
从输出可以看到，mvn clean install 实际调用了 clean 生命周期的pre-clean、clean 阶段，
以及 default 生命周期的从 validate 至 install 所有阶段。
b） 自定义绑定
除了内置绑定以外，用户还能够自己选择将某个插件目标绑定到生命周期的某个阶段上，
这种自定义绑定方式能让 Maven 项目在构建过程中执行更多、更丰富特色的任务。
i. 创建项目的源码 jar 包
内置的插件绑定关系中并没有设计这一任务，需要用户自行配置。
maven-source-plugin 可以帮助我们完成该任务，它的 jar-no-fork 目标能
够将项目的主代码打包成 jar 文件。可以将其绑定到 default 生命周期的verify 阶段上，
在执行完集成测试后和安装构件之前创建源码 jar 包。
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>2.1.2</version>
<executions>
<execution>
<id>attach-sources</id>
<phase>verify</phase>
<goals>
<goal>jar-no-fork</goal>
</goals>
</execution>
</executions>
</plugin>
1） 稳定性
对自定义绑定的插件，应该声明一个非快照版本来保证构建的稳定。
2） execution
配置执行一个 id 为 attach-sources 的任务，通过 phase 配置绑定到verify 生命周期阶段上，
再通过 goals 配置指定要执行的插件目标。
3） 默认绑定阶段
有很多插件的目标在编写时已经定义了默认绑定阶段，删除上面 phase一行配置，
再次执行 mvn verify，效果仍然一样。
4） 执行顺序
当插件目标被绑定到不同的生命周期阶段，其执行顺序会由生命周期阶段的先后顺序决定。
如果多个目标被绑定到同一阶段，他们的执行会是？当多个插件目标绑定到同一阶段的时候，
这些插件声明的先后顺序决定了目标的执行顺序。
3. 插件配置
完成了插件和生命周期的绑定之后，还可以配置插件目标的参数，进一步调整插件目标所执行的任务，
几乎所有的 Maven 插件都有一些可配置的参数。
a） 命令行配置
在命令中使用-D 参数，并伴随一个参数键=参数值的形式配置。
例如：install–Dmaven.test.skip=true。
i. –D 参数
是 Java 自带，功能是通过命令行设置一个 Java 系统属性，Maven 简单地重用了该参数。
ii. maven-surefire-plugin
maven-surefire-plugin 提供一个 maven.test.skip 参数，当其值为 true的时候，
就会跳过执行测试。
b） pom 中插件全局配置
并不是所有插件参数都适合命令行配置，有些参数的值从项目创建到项目发布都不会改变，
或者说很少改变，对于这种情况，在 pom 文件中一次性配置就显得比重复在命令行输入要方便。
用户可以在声明插件的时候，对此插件进行一个全局的配置。也就是说，
所有该基于该插件目标的任务，都会使用这些配置。
例如：编译 Java 源文件版本。
i. 编译 Java 源文件版本
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<configuration>
<source>1.6</source>
<target>1.6</target>
</configuration>
</plugin>
</plugins>
</build>
c） pom 中插件任务配置
除了为插件配置全局的参数，还可以为某个插件任务配置特定的参数。例如：
maven-antrun-plugin，有一个 run 目标，可以用来在 Maven 中调用 Ant 任务。
用户将 maven-antrun-plugin:run 绑定到多个生命周期阶段上，再加以不同的配置，
就可以让 Maven 在不同的生命阶段执行不同的任务。
代码：略。
4. 获取插件信息
Maven 的插件非常多，而且大部分都没有完善的文档。正确的插件并进行正确的配置，
其实不是一个简单的事情，要学会去哪里找合适的插件，以帮助完成任务。
a） 在线插件信息
i. Apache
http://maven.apache.org/plugins/index.html
ii. Codehaus
http://mojo.codehaus.org/plugins.html
b） 使用 maven-help-plugin 描述插件
除了访问在线的插件文档外，还可以借助 maven-help-plugin 来获取插件的详细信息，
可以运行如下命令来获取 maven-compiler-plugin2.1 版本的信息：
mvn help: describe-Dplugin = org.apache.maven.plugins:maven-compiler-plugin:2.1
i. maven-help-plugin
maven-help-plugin 的 describe 目标，在参数 plugin 中输入需要描述插件的 groupId、
artifactId 和 version。Maven 在命令行输出maven-compiler-plugin 的简要信息，
包含插件的坐标、目标前缀和目标等。
5. 目标前缀
为了达到清晰、简洁的命令使用，Maven 引入了目标前缀的概念，
help 是maven-help-plugin 的目标前缀，dependency 是 maven-dependency-plugin 的前缀，
有了插件前缀，Maven 就能找到对应的 artifactId。不过，除了 artifactId，
Maven 还需要 groupId 和 version 才能精确定位到某个插件。
6. 插件解析机制
为了方便用户使用和配置插件，Maven 不需要用户提供完整的插件坐标信息，
就可以解析得到正确的插件，有好处也有坏处，虽然简化了插件的使用和配置，
可一旦插件出现异常行为，很难快速定位到出额外难题的插件构件。
a） 插件仓库
与依赖构件一样，插件构件同样基于坐标存储在 Maven 仓库中。
i. 和依赖仓库区别
Maven 会区别对待依赖的远程仓库和插件的远程仓库，与依赖的远程仓库配置不一样。
ii. 插件远程仓库配置
<pluginRepositories>
<pluginRepository>
<id>central</id>
<name>Maven Plugin Repository</name>
<url>http://repo1.maven.org/maven2</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</pluginRepository>
</pluginRepositories>
iii. 一般来说，中央仓库所包含的插件完全能满足我们的需要。
b） 插件的默认 groupId
在 pom 中配置插件的时候，如果该插件是 Maven 官方的插件
（也就是说，如果其 groupId 为 org.apache.maven.plugins），就可以省略 groupId 配置。
c） 解析插件版本
如果用户没有提供插件的版本信息。
i. 核心插件都预先设定了版本
ii. 检查所有仓库中的可用版本做出选择
maven-metadata.xml 元数据文件，latest 表示所有仓库中该构件的最新版本，
release 表示最新的非快照版本。
1） maven2
插件版本会解析至 latest。
2） maven3
插件版本会解析至 release。
iii. 依赖 Maven 解析插件版本其实是不推荐的做法
d） 解析插件前缀
插件前缀与groupId:artifactId是一一对应的，这种匹配关系存储在仓库元数据中，
这里提到的仓库元数据。
i. groupId/maven-metadata.xml
1） http://repo1.maven.org/maven2/org/apache/maven/plugins/
2） http://repository.codehaus.org/org/codehaus/mojo/
ii. 自定义检查其他groupId上的插件仓库元数据
<settings>
<pluginGroups>
<pluginGroup>com.your.plugins</pluginGroup>
</pluginGroups>
</settings>
Maven就会检查com/your/plugins/maven-metadata.xml
iii. 举例说明（dependency:tree）
首先基于默认的groupId归并所有插件仓库的元数据
org/apache/maven/plugins/maven-metadata.xml，其次检查归并后的元数据，
找到对应的artifactId为maven-dependency-plugin，然后结合当前元数据的groupId，
org.apache.maven.plugins，再根据版本解析方式得到版本信息，最终得到完整的插件坐标。
apache不包含就检索codehaus，如果还没有就检索用户自定义的插件组，
如果所有元数据中都不包含该前缀，则报错。