maven笔记

默认中央仓库：
http://repo1.maven.org/maven2
https://repo.maven.apache.org/maven2

-DskipTests=true 不执行测试用例，但编译测试
-Dmaven.test.skip=true 不执行测试用例，也不编译测试用例类

生命周期
clean 清理项目
default 构建项目
site 生成项目站点文档

生命周期对应的阶段
clean生命周期
pre-clean 执行一些清理前需要完成的工作
clean 清理上一次构建生成的文件
post-clean

default生命周期
validate 校验项目是否正确，检查必要信息是否可用
initialize 构建状态初始化（比如，设置属性或生成目录）
generate-source 生成编译中包含的源代码
process-source 处理源代码（如过滤一些值）
generate-resources 生成打包包含的资源文件
process-resources 复制并处理资源到目标目录，准备打包
compile 编译项目源代码
process-classes 后处理编译生成的文件，例如：对class文件进行字节码增强
generate-test-sources 生成编译中包含的测试源码
process-test-sources 处理测试源代码，例如：过滤一些值
generate-test-resources 创建测试用的资源文件
process-test-resources 复制并处理资源到目标测试目录
test-compile 编译测试源码放入测试目标文件夹中
process-test-classes 后处理测试编译生成的文件，例如：对class文件进行字节码增强，对Maven 2.0.5及以上有效
test 使用单元测试框架运行测试。测试代码不会被打包或者部署。
prepare-package 执行必要的操作，在真正打包前准备一个包。这通常会产生一个未打包、处理过版本。（Maven 2.1及以上）
package 接受编译好的代码，打包成可发布的格式，如：JAR
pre-integration-test 在集成测试执行前进行些必要的操作。这也许会涉及相关的东西，例如安装必须的环境。
integration-test 处理并将包文件部署到集成测试运行的环境
post-integration-test 集成测试执行之后进行的必要操作。这可能包含了清理环境操作。
verify 运行一些校验去验证包是否有效，是否符合质量标准。
install 安装包到本地仓库，供本地其他项目依赖使用
deploy 将最终的包复制到远程仓库，供其他开发人员和Maven项目使用

site生命周期
pre-site 执行一些在生成站点之前需要完成的工作
site 生成项目站点文档
post-site 执行一些在生成站点之后需要完成的工作
site-deploy 将生成的站点文件发布到远程服务器上

插件目标（Plugin Goal）

插件能够为Maven提供不同的功能，而一个插件可能包含多个插件目标。比如，如下是插件 maven-dependency-plugin 包含的三个插件目标：
插件目标 作用
dependency:analyze 分析项目依赖
dependency:tree 列出项目依赖树
dependency:list 列出项目所有已解析的依赖
命令中使用冒号（：）分隔插件和插件目标，比如compiler:compile表示 maven-compiler-plugin 插件的 compile 目标。

插件绑定（Plugin Binding）
前面说过，Maven只是定义了抽象的生命周期，生命周期阶段具体执行的操作是由其绑定的插件目标实现的。也就是说插件目标有一下两种方式被执行：
通过绑定到生命周期阶段，而在生命周期阶段执行时被调用
通过直接调用的方式（也就是“plugin:goal”的方式）在生命周期阶段外执行
NOTE：一个插件目标可以绑定到多个生命周期阶段，一个生命周期阶段也能绑定多个插件。一个生命周期阶段绑定多个插件目标的情况，其执行顺序是按照POM文件中插件目标定义的顺序。

默认插件绑定

我们怎样才能够绑定插件目标到生命周期的阶段呢？两种方式：

Maven内置默认绑定
在POM文件中自定义绑定
对于default生命周期，Maven会根据不同的packaging，绑定不同的插件目标。

Clean 生命周期绑定

生命周期 插件目标
clean clean:clean
Default 生命周期绑定 - Packaging ejb/ejb3/jar/par/rar/war

生命周期 插件目标
process-resources resources:resources
compile compiler:compile
process-test-resources resources:testResources
test-compile compiler:testCompile
test surefire:test
package ejb:ejb或ejb3:ejb3或jar:jar或par:par或rar:rar或war:war
install install:install
deploy deploy:deploy
Site 生命周期绑定

生命周期 插件目标
site site:site
site-deploy site:deploy
其他默认的插件目标绑定请参考Maven官方文档。

自定义绑定

自定义绑定可将一个插件目标绑定到任意构建生命周期阶段上。要实现自定义绑定，需要在project > plugins > plugin中声明。

<project>
...
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>2.1.1</version>
<executions>
<execution>
<id>attach-sources</id>
<phase>verify</phase>
<goals>
<goal>jar-no-fork</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
...
</project>

以上示例中，声明了maven-source-plugin（使用groupId、artifactId、version指定）。然后在<executions>元素下指定多个任务<execution>，通过指定多个<execution>，就可以把相同插件的目标绑定到不同的生命周期阶段。<id>指定任务名称（在一个插件中必须唯一），<phase>指定到的生命周期阶段，<goal>指定插件目标。

如果没有指定<phase>，那么就会绑定到插件默认的生命周期阶段上。如果插件没有默认生命周期阶段，那么插件目标将不会被执行。

通过以上的配置，现在执行mvn verify将看到maven-source-plugin的jar-no-fork目标被执行。

插件配置

几乎每个插件都有可配置的参数，以满足不同的构建需求。

命令行插件配置

执行生命周期或插件目标时，如果某个插件目标被调用，那么就可以通过-D{parameter}的形式指定参数的配置。如：

mvn myquery:query -Dquery.url=http://maven.apache.org
1
POM 文件全局配置

在project > build > plugins > plugin > configuration中配置的参数，将在每一次执行该插件的时候起作用。

<project>
[...]
<build>
[...]
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.5.1</version>
<configuration>
<source>1.7</source>
<target>1.7</target>
</configuration>
</plugin>
</plugins>
[...]
</build>
[...]
</project>

以上配置了maven-compiler-plugin插件使用 java 1.7 编译源代码，那么无论在compile生命周期中被调用，还是手动调用该插件，都会使用 java 1.7。

POM 文件插件任务配置

在 project > build > plugins > plugin > executions > execution > configuration 中配置的参数，只在该任务被执行时有效。

命令行执行插件

执行mvn -h看到如下帮助信息：

$ mvn -h

usage: mvn [options] [<goal(s)>] [<phase(s)>]
options：mvn 命令选项
goal(s)：插件目标
phase(s)：生命周期阶段
根据以上知识，如果执行以下命令：

mvn clean dependency:copy-dependencies package
1
那么，clean阶段会首先执行（包括在它以前的阶段），然后是dependency:copy-dependencies插件目标，最后package阶段被执行（包括它之前的阶段）。而生命周期阶段被执行也就是插件目标被执行，所以整个命令最终就是不同的插件目标执行，然后完成了想实现的目标。

插件前缀解析

Maven中标识插件也是使用groupId:artifactId:version，但是实例中命令行调用都只有一个前缀和目标，比如dependency:copy-dependencies。

Maven允许使用插件前缀来映射groupId:artifactId，Maven有多种方式来指定这种映射方式。

根据约定确定

默认情况下，Maven通过去除artifactId上通过连字符连接的maven和plugin来确定插件前缀：

maven-${prefix}-plugin：官方插件使用的artifactId
${prefix}-maven-plugin：其他来源的插件（如 tomcat 插件：tomcat7-maven-plugin）
使用以上两种方式，Maven能够通过artifactId的形式，自动确定插件前缀。这样你就能够使用tomcat7作为前缀来调用 tomcat 插件的目标，如tomcat7:run。

手动指定

可以在声明插件时手动指定插件前缀：

<project>
...
<build>
...
<plugins>
...
<plugin>
<artifactId>maven-plugin-plugin</artifactId>
<version>2.3</version>
<configuration>
...
<goalPrefix>somePrefix</goalPrefix>
</configuration>
</plugin>
</plugins>
</build>
</project>
现在可以使用somePrefix前缀来使用插件了：

mvn somePrefix:goal
1
配置Maven搜索插件前缀

如果，每个人都自己指定插件前缀，那么每个人的配置都不一样，那么岂不麻烦。maven就是为了消除这些麻烦，所以使用约定优于配置的原则来构建。

所以，很多插件都自己指定了插件前缀。那么，Maven是如何解析这些前缀的呢？

这些映射关系都放在groupId/maven-metadata.xml中，所以，Maven使用如下的方式解析插件前缀：

在${groupId}路径下，下载远程仓库的maven-metadata.xml到该路径，然后重命名为maven-metadata-${repoId}.xml。
合并${groupId}路径下的maven-metadata-local.xml，然后加载合并后的文件。
然后在合并后的元数据中查找插件前缀，如果没找到就在下一个插件组重复这一过程。
如下是Maven官方插件（groupId为org.apache.maven.plugins）路径下的maven-metadata.xml文件的片段：

<plugins>
<plugin>
<name>Apache Maven Clean Plugin</name>
<prefix>clean</prefix>
<artifactId>maven-clean-plugin</artifactId>
</plugin>
<plugin>
<name>Apache Maven Compiler Plugin</name>
<prefix>compiler</prefix>
<artifactId>maven-compiler-plugin</artifactId>
</plugin>
<plugin>
<name>Apache Maven Dependency Plugin</name>
<prefix>dependency</prefix>
<artifactId>maven-dependency-plugin</artifactId>
</plugin>
</plugins>

可以看到，每个plugin元素指定了prefix和artifactId，所以这个插件前缀就唯一确定了groupId:artifactId，再结合声明插件时指定的version信息，Maven就完成了插件的解析。
Maven默认会搜索如下两个groupId下的插件：

org.apache.maven.plugins
org.codehaus.mojo
如果，需要Maven搜索更多groupId下的插件，那么需要在settings.xml中配置<pluginGroups>元素：

<pluginGroups>
<pluginGroup>org.codehaus.modello</pluginGroup>
</pluginGroups>
这样，Maven就会首先搜索org.codehaus.modello下的插件前缀，如果没有找到，再搜索org.apache.maven.plugins、org.codehaus.mojo。也就是<pluginGroup>中配置的groupId优先级高于Maven默认的。这样，可以使用这一机制来覆盖默认的插件前缀的解析。

依赖：
provided 不具有传递性
optional 依赖可选的，不具有传递性

访问属性：
${env.propertyName} 环境变量
${project.propertyName} 项目的
${settings.localRepository} maven配置文件中的
${java.home} java.lang.System.getProperties()
${hello.world} pow文件中的

将source-plugin置于顶层或parent的pom中并不会发挥作用，必须置于具体项目的pom中。

查看插件信息
mvn help:describe -Dplugin=org.apache.maven.plugins:maven-assembly-plugin:3.0.0 -Ddetail
mvn assembly:help