Apache Maven是一个项目管理工具(包括项目构建,依赖管理,信息管理)。它基于POM(Project Object Model),可以为Java项目提供强大的管理功能。
构建工具的作用
构建工具指的是把构建过程自动化的工具,包含以下过程:
- 生成源代码(如果使用了代码生成工具)
- 生成文档,根据源代码
- 编译源代码
- 将编译后的代码打包为jar文件或zip文件
- 安装打包文件到本地仓库、远程仓库或中央仓库
Maven生命周期
Maven生命周期(Build Lifecycle)就是对构建过程的抽象,也就是说Maven使用生命周期来完成项目的构建。但是,maven只定义了抽象的生命周期,具体的实现是由插件来完成的(类似于模板方法设计模式)。
Maven包含三套内置的生命周期:
周期 | 作用 |
---|---|
clean | 清理项目 |
default | 构建项目 |
site | 生成项目站点文档 |
阶段(phases)
每个生命周期都包含不同的阶段,这些阶段都是有顺序的,当你执行一个阶段时,处于该生命周期下的当前执行阶段之前的阶段都会被执行,以确保顺利的构建。三套生命周期分别包含以下阶段:
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 生命周期绑定 - Packagingejb
/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>
- 1
- 以上示例中,声明了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>
- 1
以上配置了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
配置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默认的。这样,可以使用这一机制来覆盖默认的插件前缀的解析。
总结
本文重点介绍了Maven中很重要的生命周期和插件的概念,能够帮助学习者从原理方面来理解Maven,加强学习的效果。
参考
Introduction to the Build Lifecycle
Guide to Configuring Plug-ins
Introduction to Plugin Prefix Resolution
《Maven实战》
《Mavan官方文档》构建生命周期介绍