maven教程3_maven-compiler-plugin

作者: 文思li | 来源:发表于2018-04-21 13:13 被阅读0次

原创者：文思

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也知道源文件的默认位置：