原文连接:https://blog.csdn.net/u012152619/article/details/51473404
maven生命周期
在Maven中有三套独立的生命周期:
- Clean Lifecycle:在进行真正的构建之前进行一些清理工作。
- Default Lifecycle:构建的核心部分,编译、测试、打包、部署。
- Site Lifecycle:生成项目报告、生成站点、发布站点。
再次强调一下它们是相互独立的,可以仅仅调用clean来清理工作目录,仅仅调用site来生成站点。当然也可以直接运行 “mvn clean install site” 运行所有这三套生命周期。
每套生命周期都由一组阶段(Phase)组成,我们平时在命令行输入的命令总会对应于一个特定的阶段。maven中所有的执行动作(goal)都需要指明自己在这个过程中的执行位置,然后maven执行的时候,就依照过程的发展依次调用这些goal进行各种处理。这个也是maven的一个基本调度机制。
每套生命周期还可以细分成多个阶段。
Clean生命周期
Clean生命周期一共包含了三个阶段:
Clean生命周期 | |
pre-clean | 执行一些需要在clean之前完成的工作 |
clean | 移除所有上一次构建生成的文件 |
post-clean | 执行一些需要在clean之后立刻完成的工作 |
命令“mvn clean”中的就是代表执行上面的clean阶段,在一个生命周期中,运行某个阶段的时候,它之前的所有阶段都会被运行,也就是说,“mvn clean” 等同于 “mvn pre-clean clean” ,如果我们运行“mvn post-clean” ,那么 “pre-clean”,“clean” 都会被运行。这是Maven很重要的一个规则,可以大大简化命令行的输入。
Default生命周期
Maven最重要就是的Default生命周期,也称构建生命周期,绝大部分工作都发生在这个生命周期中,每个阶段的名称与功能如下:
Default生命周期 | |
validate | 验证项目是否正确,以及所有为了完整构建必要的信息是否可用 |
generate-sources | 生成所有需要包含在编译过程中的源代码 |
process-sources | 处理源代码,比如过滤一些值 |
generate-resources | 生成所有需要包含在打包过程中的资源文件 |
process-resources | 复制并处理资源文件至目标目录,准备打包 |
compile | 编译项目的源代码 |
process-classes | 后处理编译生成的文件,例如对Java类进行字节码增强(bytecode enhancement) |
generate-test-sources | 生成所有包含在测试编译过程中的测试源码 |
process-test-sources | 处理测试源码,比如过滤一些值 |
generate-test-resources | 生成测试需要的资源文件 |
process-test-resources | 复制并处理测试资源文件至测试目标目录 |
test-compile | 编译测试源码至测试目标目录 |
test | 使用合适的单元测试框架运行测试。这些测试应该不需要代码被打包或发布 |
prepare-package | 在真正的打包之前,执行一些准备打包必要的操作 |
package | 将编译好的代码打包成可分发的格式,如JAR,WAR,或者EAR |
pre-integration-test | 执行一些在集成测试运行之前需要的动作。如建立集成测试需要的环境 |
integration-test | 如果有必要的话,处理包并发布至集成测试可以运行的环境 |
post-integration-test | 执行一些在集成测试运行之后需要的动作。如清理集成测试环境。 |
verify | 执行所有检查,验证包是有效的,符合质量规范 |
install | 安装包至本地仓库,以备本地的其它项目作为依赖使用 |
deploy | 复制最终的包至远程仓库,共享给其它开发人员和项目(通常和一次正式的发布相关) |
可见,构建生命周期被细分成了22个阶段,但是我们没必要对每个阶段都了如指掌,经常关联使用的只有process-test-resources、test、package、install、deploy等几个阶段而已。
一般来说,位置稍后的过程都会依赖于之前的过程。这也就是为什么我们运行“mvn install” 的时候,代码会被编译,测试,打包。当然,maven同样提供了配置文件,可以依照用户要求,跳过某些阶段。比如有时候希望跳过测试阶段而直接install,因为单元测试如果有任何一条没通过,maven就会终止后续的工作。
Site生命周期
Site生命周期 | |
pre-site | 执行一些需要在生成站点文档之前完成的工作 |
site | 生成项目的站点文档 |
post-site | 执行一些需要在生成站点文档之后完成的工作,并且为部署做准备 |
site-deploy | 将生成的站点文档部署到特定的服务器上 |
这里经常用到的是site阶段和site-deploy阶段,用以生成和发布Maven站点,这是Maven相当强大的功能。
Maven生命周期中常用的指令:
mvn compile //让当前项目经历生命周期中的1–>7 阶段 :完成编译主源代码编译。
mvn package //让当前项目经历生命周期中的1–>17阶段 :完成打包。
mvn install //让当前项目经历生命周期中的1–>22阶段 :完成包安装到本地仓库。
mvn deploy //让当前生命经历生命周期中的1–>23阶段 :完成包部署到中心库中。
Maven中scope标签分类
maven认为,程序对外部的依赖会随着程序的所处阶段和应用场景而变化,所以maven中的依赖关系有作用域(scope)的限制。
在maven中,scope包含如下的取值:
Scope选项 | |
compile(编译范围) | compile是默认的范围;如果没有提供一个范围,那该依赖的范围就是编译范围。编译范围依赖在所有的classpath中可用,同时它们也会被打包。 |
provided(已提供范围) | provided依赖只有在当JDK或者一个容器已提供该依赖之后才使用。例如,如果你开发了一个web应用,你可能在编译classpath中需要可用 的Servlet API来编译一个servlet,但是你不会想要在打包好的WAR中包含这个Servlet API;这个Servlet API JAR由你的应用服务器或者servlet容器提供。已提供范围的依赖在编译classpath(不是运行时)可用。它们不是传递性的,也不会被打包。 |
runtime(运行时范围) | runtime依赖在运行和测试系统的时候需要,但在编译的时候不需要。比如,你可能在编译的时候只需要JDBC API JAR,而只有在运行的时候才需要JDBC驱动实现。 |
test(测试范围) | test范围依赖在编译和运行时都不需要,它们只有在测试编译和测试运行阶段可用。 |
system(系统范围) | system范围依赖与provided类似,但是你必须显式的提供一个对于本地系统中JAR文件的路径。这么做是为了允许基于本地对象编译,而这些对象是系统类库的一部分。这样的构件应该是一直可用的,Maven也不会在仓库中去寻找它。 如果你将一个依赖范围设置成系统范围,你必须同时提供一个systemPath元素 。注意该范围是不推荐使用的(应该一直尽量去从公共或定制的Maven仓库中引用依赖)。 |
scope的依赖传递
A依赖B,B依赖C。当前项目为A,只当B在A项目中的scope,那么c在A中的scope是如何得知呢?
当C是test或者provided时,C直接被丢弃,A不依赖C;(排除传递依赖)
否则A依赖C,C的scope继承与B的scope。
注意事项:
Intellij IDEA 中maven编译中文出现乱码
需要在Settings–maven–runner–VM Options添加 -Dfile.encoding=GB2312
参考文章
Maven探析与应用
http://blog.csdn.net/column/details/clfmaven.html
《Maven进阶》1.maven 项目生命周期与构建原理
http://blog.csdn.net/luanlouis/article/details/50492163
Maven实战:Maven生命周期
https://www.cnblogs.com/xrq730/p/5527254.html
maven中scope标签详解
http://blog.csdn.net/cd18333612683/article/details/66478332
Maven中的dependency的scope作用域详解
http://makaidong.com/a564663276/1/53219_12316918.html