前面讲了maven的依赖和仓库,这是经常接触到的一些操作。但是我们平时还会接触到maven生命周期的一些操作,比如打包、编译等,maven就可以把我们的项目进行打包、编译。其实这个过程,还是涉及到很多知识点的,只不过我们在操作过程中察觉不到而已。
我们在项目开发中都会涉及到清理、编译、测试、部署等流程,所以maven就对我们这个过程进行抽象和统一,定义了一套统一的生命周期。
maven的生命周期
maven有三套生命周期,分别是clean、default、site。
clean是用来清理项目,default是构建项目,属于maven生命周期中最核心的部分,site是建立项目站点。每套生命周期还包含很多阶段,阶段之间是有顺序的。
clean生命周期包含的阶段:
顺序 | 阶段 | 备注 |
---|---|---|
1 | pre-clean | 清理前的准备工作 |
2 | clean | 清理上次构建生成的文件 |
3 | post-clean | 清理后的工作 |
default生命周期包含的阶段:
顺序 | 阶段 | 备注 |
---|---|---|
1 | validate | 验证 |
2 | initialize | 初始化构建状态 |
3 | generate-sources | 生成源代码 |
4 | process-sources | 处理项目主资源文件 |
5 | generate-resources | 生成项目中的资源 |
6 | process-resources | 处理资源并复制资源到目标目录,为打包做准备 |
7 | compile | 编译项目主源码 |
8 | process-classes | 处理生成后的字节码文件 |
9 | generate-test-sources | 生成测试源代码 |
10 | process-test-sources | 处理项目测试资源文件 |
11 | generate-test-resources | 创建测试资源 |
12 | process-test-resources | 处理测试资源,并复制到测试目标目录中 |
13 | test-compile | 编译测试代码 |
15 | process-test-classes | 处理生成后的测试源代码的字节码 |
16 | test | 运行单元测试 |
17 | prepare-package | 打包之前进行一些操作,例如解压缩,处理版本。 |
18 | package | 打包 |
19 | pre-integration-test | 在集成测试之前进行一些操作 |
20 | integration-test | 集成测试 |
21 | post-integration-test | 执行集成测试后执行所需的操作 |
22 | verify | 检查 |
23 | install | 将包安装到maven本地仓库 |
24 | deploy | 将包复制到远程仓库 |
site生命周期包含的阶段:
顺序 | 阶段 | 备注 |
---|---|---|
1 | pre-site | 生成站点前准备工作 |
2 | site | 生成项目站点文档 |
3 | post-site | 生成站点之后的工作 |
4 | site-deploy | 将生成的站点发布到服务器上 |
maven插件
maven定义了生命周期,但是并没有具体的实现,maven定义的生命周期是抽象的,所有的实现都交由插件完成。这就在保证严格控制生命周期流程的条件下,实现了足够的扩展性。
maven插件为了能够达到复用,一个插件一般都可以完成多个功能,每个功能就是一个插件目标。
上面maven生命周期表格中的步骤,一个步骤都可以绑定一个或多个插件行为,并且为了方便起见,maven为大多数步骤都编写并绑定了默认的插件,这就是内置绑定,为了让用户不做任何配置就可以构建maven项目。除了内置绑定之外,用户还可以自己选择将某个插件目标绑定到maven某个生命周期的某个阶段,这就是自定义绑定,可以让maven项目在构建过程中执行更多自定义的任务。
下面是内置绑定中,常见的生命周期阶段和插件目标的对应关系:
(由于打包类型不同,插件也不同,这里以打包类型为jar举例)
生命周期阶段 | 插件目标 | 说明 |
---|---|---|
clean | maven-clean-plugin:clean | 清理上次构建生成的文件 |
process-resources | maven-resources-plugin:resources | 复制主资源文件至主输出目录 |
compile | maven-compiler-plugin:compile | 编译主代码至主输出目录 |
process-test-resources | maven-resources-plugin:testResources | 复制测试资源文件至测试输出目录 |
test-compile | maven-compiler-plugin:testCompile | 编译测试代码至测试输出目录 |
test | maven-surefire-plugin:test | 执行测试用例 |
package | maven-jar-plugin:jar | 创建jar包 |
install | maven-install-plugin:install | 将项目输出构件安装到本地仓库 |
deploy | maven-deploy-plugin:deploy | 将项目输出构件部署到远程仓库 |
site | maven-site-plugin:site | 编译测试代码至测试输出目录 |
site-deploy | maven-site-plugin:deploy | 编译测试代码至测试输出目录 |
除了内置绑定,用户还可以进行自定义绑定,我们有时候可以在pom文件中看到如下的配置:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>2.3</version>
<configuration>
<attach>true</attach>
</configuration>
<executions>
<execution>
<phase>compile</phase>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
这段配置,就是自定义绑定,这里定义了使用maven-source-plugin插件,executions下每个execution子元素可以配置一个任务,phase定义为compile生命周期,goal指定目标是jar,也就是maven-source-plugin插件的jar目标。所以,当通过maven执行compile生命周期时,就是执行maven-source-plugin插件的jar目标。
插件仓库
maven在解析插件时,也是先从本地仓库寻找,如果找不到,再去远程仓库寻找,但是插件的远程仓库有点特殊,和我们之前配置的依赖的远程仓库的地址不是同一个地址。
有时候,我们可能会在pom文件看到如下配置:
<pluginRepositories>
<pluginRepository>
<id>xxx-nexus</id>
<url>http://maven.xxx.com:8081/nexus/content/xxx/xxx</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</pluginRepository>
</pluginRepositories>
这段配置就是配置maven插件的远程仓库地址的,maven也有内置的插件远程仓库的地址,一般情况下,内置的插件远程仓库地址就可以满足大部分的场景了,所以自定义的插件远程仓库一般不会看到。
pom中配置插件时,如果这个插件是maven官方插件,则可以省略groupId的配置,但是一般不推荐这么使用。
参考资料:
1.《maven实战》 许晓斌 著