1.生命周期和插件的关系
命令行的输入对应了生命周期。Maven的生命周期是抽象的，只做规划，实际行为都由插件来完成。
生命周期本身不做任何实际的工作，在Maven设计中，实际的任务（如编译源代码）都交由插件来完成。
这种思想与设计模式中的模板方法一致。模板方法模式在父类中定义算法的整体结构，子类可以通过实现或者重写父类的方法来控制实际的行为，即保证了算法有足够的可扩展性，又严格控制了算法的整体结构。
maven设计了生命周期包含了初始化、编译、测试、打包、集成测试、部署等，抽象了构建的各个步骤，定义了次序，但没有提供具体实现。
此时，不可能让用户或者使用者，来编写各种实现？
因此，maven设计了插件机制。每个构建步骤都可以绑定一个或者多个插件行为，而且maven为大多数构建步骤编写并绑定了默认插件。例如，针对编译的插件有maven-compiler-plugin,针对测试的插件有maven-surefire-plugin等。
一般用户不会察觉不到差价的存在，但实际上编译是由maven-compiler-plugin完成的，而测试是由maven-surefireplugin完成的。
当有需要时，可以配置插件定制构建行为，甚至自己编写插件。
2.生命周期详解
Maven有3套互相独立的生命周期。即clean、default、site。每个生命周期包含一些阶段（phase），这些阶段是有序的，并且后面的阶段依赖于前面的阶段，用户和Maven最直接的交互方式就是调用这些生命周期阶段。
clean：清理项目【均包含clean】
1.pre-clean:执行一些清理前需要完成的工作
2.clean：清理上一次构建生成的文件
3.post-clean：执行一些清理后需要完成的工作
default：构建项目
validate
initalize
generate-sources
process-source:处理项目主资源文件。一般来说，是对src/main/resources目录的内容经行变量替换等工作，复制到项目输出的主classpath目录汇中。
generate-resources
process-resourecs
compile：编译项目的主源码。一般来说，是编译src/main/java目录下的Java文件至项目输出的classpath目录中
process-classes
generate-test-sources
process-test-sources:处理项目测试资源文件。一般来说，是对src/test/resources目录的内容经行变量替换等工作，复制到项目输出的主classpath目录汇中。
generate-test-resources
process-test-resources
test-compile:编译项目的测试源码。一般来说，是编译src/test/java目录下的Java文件至项目输出的classpath目录中
process-test-classes
test :使用单元测试框架运行测试，测试代码不会被打包或部署。
prepare-package
package 接受编译好的代码，打包成可发布的格式，如jar
pre-integration-test
integration-test
post-integration-test
verify
install 将包安装到Maven本地仓库，提供本地其他Maven项目使用
deploy 将最终的包复制到远程仓库，供其他开发人员和maven项目使用。
具体可以查看maven官网
site：建立和发布项目站点【均包含site】
pre-site：执行一些在生成项目站点之前需要完成的工作
site 生成项目站点文档
post-site 执行一些在生成项目站点之后需要完成的工作
site-deploy 将生成的项目站点发布到服务器上。
命令行与生命周期
命令行就是 mvn + 阶段。。。
示例：
mvn clean ：执行clean生命周期的clean阶段，实际执行的阶段为clean生命周期的pre-clean和clean阶段
mvn test：执行default生命周期的test阶段，实际执行的阶段为default生命周期的从开始直到test的所有阶段
mvn clean install：执行clean生命周期的clean阶段，和执行default生命周期的install阶段
mvn clean deploy site-deploy：
了解以上基础生命周期及阶段，就可以使用mvn命令了
3.插件目标
将多个功能聚集在一个插件里，每个功能就是一个插件目标。
4.插件绑定
Maven的生命周期与插件相互绑定，用以完成实际的构建任务。具体而言，是生命周期的阶段与插件的目标相互绑定，已完成某个具体的构建任务。
内置绑定
为了能让用户几乎不用任何配置就能构建Maven项目，Maven在核心为一些主要的声明周期阶段绑定了很多插件的目标，当用户通过命令行调用声明周期阶段的时候，对应的插件目标就会执行相应的任务。
示例
自定义绑定
示例:创建项目的源码jar包，插件maven-source-plugin，他的jar-no-fork目标能够将项目的主代码打包成jar文件。可以将其绑定到default的verify阶段
POM中的build的plugins下的插件
phase是阶段的意思，执行在verify阶段
执行mvn verify，即可输出源码jar包
5.插件配置
1.命令行插件配置
示例：maven-surefire-plugin提供了一个maven.test.skip参数，当其为true的时候，就会跳过执行测试，
mvn install -D maven.test.skip=true
2.POM中插件全局配置
示例： 编译源文件，字节码的jvm版本
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.5.1</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
3.POM中插件任务配置
示例：maven调用ant任务，
6.获取插件信息
1.在线插件信息
apache：http://maven.apache.org/plugins/
codehaus：
2.使用maven-help-plugin描述插件
mvn help:describe -D plugin=org.apache.maven.plugins:maven-compiler-plugin:2.1
命令进一步简化
mvn help:describe -D plugin=compiler
如果想仅仅描述某个插件的目标信息，可以加上goal参数
mvn help:describe -D plugin=compiler -D goal=compile
输出更详细的
mvn help:describe -D plugin=compiler -Ddetail
7.命令行调用插件
mvn -h
8.插件解析机制
1.插件仓库
插件构建同样基于坐标存储在maven中。
maven 配置中会有插件地址
2.插件的默认groupId
在POM中配置插件的时候，如果该插件是Maven的官方插件（即groupId为org.apache.maven.plugins）,就可以省略groupId配置。【不推荐】
示例：
3.解析插件版本
为了简化插件的配置和使用，在用户没有提供插件版本的情况下，Maven会自动解析插件版本
首先，Maven在超级POM中为所有核心插件设定了版本，超级POM是所有Maven项目的父POM。所有项目都继承写个超级POM的配置。
如果用户使用某个插件时没有设定版本，而这个插件又不属于核心插件的范畴，Maven回去检查所有仓库中的可用版本作出选择。
maven3，解析机制，当插件没有声明版本的时候，不在解析至latest，而是使用release。避免使用快照版本而导致插件行为不稳定
尽量设定版本
4.解析插件前缀
支持使用插件前缀来简化插件的调用。
插件前缀与groupid，artifactid是一一对应的，这种匹配关系存储在仓库的元数据中。