原创者：文思
org.apache.maven.plugins系列插件简介
一、插件知识简介
简介：
compiler插件3.0之前，默认的Java编译器就的JDK自带的javac。但是从Compiler插件3.0开始（需要JDK1.6），默认的Java编译器 是javax.tools.JavaCompiler。如果仍然希望使用JDK自带的javac编译源代码，就需要为mvn命令配置forceJavacCompilerUse启动参数如：-Dmaven.compiler.forceJavacCompilerUse=true
Compiler插件编译时和编译后运行的JVM版本目前默认的设置为1.5，默认用此版本，而不是根据你项目中指定的jdk版本编译。如果你想改变这些默认设置，你应该设置编译源和目标中java编译器的目标，通过设置Java源代码兼容的JVM版本，标明Java源代码开发过程中使用的Java版本，通过设置编译后的类库拟运行的JVM版本，给出编译后的类库将要运行的Java环境(一般都会设置，因为很少有项目再用1.7以下的版本了)：
同时，命令mvn的运行需要依赖JDK，Compiler插件默认使用当前运行mvn命令的JDK去编译Java源代码。如果想使用其他版本的JDK(比如本地java环境的，而非maven自带的)编译Java源代码，则需要设置如下(重点fork 、executable、compilerVersion)：
上述配置中，用以编译Java源代码的是JDK 1.8,运行mvn命令时指定maven所使用的是JDK为1.6
Compiler插件提供了如下2个goal，默认都已经绑定到Maven的生命周期阶段，无需单独指出。
compiler:compile，绑定到compile 阶段，用以编译main/路径下的源代码
compiler:testCompile，绑定到test-compile阶段，用以编译test/路径下的源代码
mvn compile:
下图看出官网也建议指定编译的jdk版本:
如果是web项目，就需要打war包，那就需要这个插件：
${project.build.sourceEncoding}强制字符集编码
platformwar包名字——platform.war
${project.build.directory}/platform
产生war前，用于存放构建war包的目录——target/platform。D�rH�4�
产生war前，用于存放构建war包的目录——target/platform。
使用maven工具链：
使用不同的JDK的最好方法是使用工具链方式。在建立一个项目，如编译java源文件，生成Javadoc，运行单元测试、打包，这些插件中的每一个都需要一个JDK工具来对应操作：Javac、JavaDoc、JaveNeR等。使用Maven工具链插件，您可以为所有相关的Maven插件配置1个默认JDK工具链也可以各自配置不同的jdk，用法略。
配置编译插件：
除工具链方式之外，也可以在编译过程中使用的特定JDK。这样的配置对这个插件是特定的，不会影响其他插件。compilerVersion参数可以用来指定插件使用的编译器版本，但是需要将fork设置为true才能工作，此为非常用配置不做详细了解。
针对不同的编译器设置source和target选项：
有时编译某个项目时需要使用的jdk与当前maven所使用的版本不同。Javac可以使用source和target参数来接受这样的命令。编译器插件也可以被配置为在编译期间提供这些选项。如刚才上述：官网也建议指定编译的jdk版本
传递编译参数：
有时需要传递其他编译器参数，这些编译器参数本身不是插件本身需要处理的，而是需要将编译器参数传递给Javac编译器，如下图
二、POM简介
所有的 POM 都继承自一个父 POM（无论是否显式定义了这个父 POM），它包含了一些可以被继承的默认设置。Maven 使用 effective pom（Super pom 加上工程自己的配置）来执行相关，目的为了使开发者在 pom.xml中做尽可能少的配置，且在子配置中可以被方便的覆盖：
比如不指定packing时，即默认打jar包时打开effective pom：
再看另一种举例：
当指定packing为war，指定打war包时打开effective pom：
所以我们只需要指定packing打包类型,maven插件可以自动加载并继承父pom相关配置。
如果父pom中的默认配置不符合现有项目要求，而在我们的pom中有没有覆盖，则会抱错，如删除pom中的maven-compiler-plugin，使其不覆盖父pom中的maven-compiler-plugin，这样就是使用的父pom中的配置：
上图删除了pom中的maven-compiler-plugin，再看下图effecrive pom中的：
看到这样就使用了默认父pom的maven-compiler-plugin2.3.2版本，此版本默认的jdk是1.5，maven编译时报：
然后修改自己的pom中的maven-compiler-plugin覆盖父pom中的maven-compiler-plugin，使用自定义覆盖默认配置：
上图pom中增加了maven-compiler-plugin，再看下图effecrive pom中的：
则使用jdk1.7编译成功了
常用插件：
maven的属性值的占位符，类似EL，类似ant的属性，比如${X}，可用于pom文件任何赋值的位置。有以下分类：
env.X：操作系统环境变量，比如${env.PATH}
project.x：pom文件中的属性，比如：1.0，引用方式：${project.version}
settings.xml文件中的属性，比如：false，引用方式：${settings.offline}
Java System Properties：java.lang.System.getProperties()中的属性，比如java.home，引用方式：${java.home}
自定义在pom文件中可以：c:/apps/cargo-installs定义属性及属性的值，而引用方式为：${installDir}
三、工作机制
Maven强大的一个重要的原因是它有一个十分完善的生命周期模型(lifecycle),它有三套相互独立的生命周期，请注意这里说的是“三套”，请别将Maven的生命周期看成一个整体哦，三个生命周期是独立线性执行，分别是：
Clean Lifecycle 在进行真正的构建之前进行一些清理工作。
Default Lifecycle 构建的核心部分，编译，测试，打包，部署等等。
Site Lifecycle 生成项目报告，站点，发布站点。
每个生命周期包含一些阶段(phase)，这些阶段（phase）是有顺序的，每个阶段蕴含一个或多个目标（goal），并且后面的阶段依赖于前面的阶段，我们和Maven最直接的交互方式就是调用这些生命周期阶段。较之于生命周期阶段的前后依赖关系，三套生命周期本身是相互独立的，用户可以仅仅调用clean生命周期的某个阶段，或者仅仅调用default生命周期的某个阶段，而不会对其他生命周期产生任何影响。例如，当用户调用clean生命周期的clean阶段的时候，不会触发default生命周期的任何阶段。其中deault是最重要的生命周期，拥有validate 、compile 、test 、package、integration、verify、install、deploy等等阶段。
看一下Maven的编译阶段，让maven进行编译代码，使用的是声明的方式来告知Maven如何做的。看似一个简单的命令，但其实它后面执行了一系列的工作。mvn compile如不指定compile阶段的goal，所以complie阶段所有goal，compile和test compile都会执行。
Maven是如何知道从哪里找到要编译的源文件？并且Maven如何知道将编译好的类文件放到哪里？这里就是由Mave基础工作之一“通过配置进行约定”所解决的问题。一般情况下，源文件放在src/main/java路径下，这种默认设置（虽然在上面的POM文件中并没看到）是从父 POM继承来的，即使最简单的POM也知道源文件的默认位置：
当首次执行compile命令或其它命令时，maven会下载所有插件和相关的文件，而之后再执行同一个命令的时候会发现比第一次快很多，这就为什么首次执行命令时候会比较慢的原因。
大家有没有想过，如果maven自带的插件满足不了我们的需求时候，该怎么办呢?其实不难办，可以通过自己写插件来实现。下面给大家讲一下如何写插件。
1、首先需要创建一个maven项目tinaproject,然后把pom里的packaging改成maven-plugin
然后把版本改为你自己使用的版本，一般现在都是用maven2
接着添加依赖
2、pom修改完了之后就开始创建mojo类了，maven插件里每一个goal所对应的功能都是一个Mojo，比如说eclipse:clean和eclipse:eclipse就是两个Mojo
写完了一个最简单的mojo类之后就来测试下能否正确运行，把mvn install吧它发布到本地maven仓库，然后在pom里再增加一个plugin（就是我自己写的这个）
最后再运行mvn compile 就能看到输出了
