Maven学习总结(44)——Maven构建时生命周期及其常用集成命令详解

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://zhanghaiyang.blog.csdn.net/article/details/79420272

集成命令:-U -X -B -e

clean能够保证上一次构建的输出不会影响到本次构建。

使用deploy而不是install: 构建的SNAPSHOT输出应当被自动部署到私有Maven仓库供他人使用,这一点在前面已经详细论述。
使用-U参数: 该参数能强制让Maven检查所有SNAPSHOT依赖更新,确保集成基于最新的状态,如果没有该参数,Maven默认以天为单位检查更新,而持续集成的频率应该比这高很多。
使用-e参数:如果构建出现异常,该参数能让Maven打印完整的stack trace,以方便分析错误原因。
使用-Dmaven.repo.local参数:如果持续集成服务器有很多任务,每个任务都会使用本地仓库,下载依赖至本地仓库,为了避免这种多线程使用本地仓库可能会引起的冲突,可以使用-Dmaven.repo.local=/home/juven/ci/foo-repo/这样的参数为每个任务分配本地仓库。
使用-B参数:该参数表示让Maven使用批处理模式构建项目,能够避免一些需要人工参与交互而造成的挂起状态。
使用-X参数:开启DEBUG模式。
综上,持续集成服务器上的集成命令应该为 mvn clean deploy -B -e -U -Dmaven.repo.local=xxx 。此外,定期清理持续集成服务器的本地Maven仓库也是个很好的习惯,这样可以避免浪费磁盘资源,几乎所有的持续集成服务器软件都支持本地的脚本任务,你可以写一行简单的shell或bat脚本,然后配置以天为单位自动清理仓库。需要注意的是,这么做的前提是你有私有Maven仓库,否则每次都从Internet下载所有依赖会是一场噩梦。
mvn clean install
生命周期阶段 描述
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 在真正的打包之前,执行一些准备打包必要的操作。这通常会产生一个包的展开的处理过的版本(将会在Maven 2.1+中实现)
package 将编译好的代码打包成可分发的格式,如JAR,WAR,或者EAR
pre-integration-test 执行一些在集成测试运行之前需要的动作。如建立集成测试需要的环境
integration-test 如果有必要的话,处理包并发布至集成测试可以运行的环境
post-integration-test 执行一些在集成测试运行之后需要的动作。如清理集成测试环境。
verify 执行所有检查,验证包是有效的,符合质量规范
install 安装包至本地仓库,以备本地的其它项目作为依赖使用
deploy 复制最终的包至远程仓库,共享给其它开发人员和项目(通常和一次正式的发布相关)
mvn jar:jar     JAR打包默认的目标
生命周期阶段 目标
process-resources resources:resources
compile compiler:compile
process-test-resources resources:testResources
test-compile compiler:testCompile
test surefire:test
package jar:jar
install install:install
deploy deploy:deploy
POM打包默认的目标
生命周期阶段 目标
package site:attach-descriptor
install install:install
deploy deploy:deploy
EJB打包默认的目标
生命周期阶段 目标
process-resources resources:resources
compile compiler:compile
process-test-resources resources:testResources
test-compile compiler:testCompile
test surefire:test
package ejb:ejb
install install:install
deploy deploy:deployMaven提供了对EJB 2和3的支持。必须配置EJB插件来为EJB3指定打包类型,否则该插件默认认为EJB为2.1,并寻找某些EJB配置文件是否存在。
WAR打包默认的目标
生命周期阶段 目标
process-resources resources:resources
compile compiler:compile
process-test-resources resources:testResources
test-compile compiler:testCompile
test surefire:test
package war:war
install install:install
deploy deploy:deploy注意war:war插件需要一个web.xml配置文件在项目的src/main/webapp/WEB-INF目录中。
EAR打包默认的目标 生命周期阶段 目标
generate-resources ear:generate-application-xml
process-resources resources:resources
package ear:ear
install install:install
deploy deploy:deploy

Maven提供了三个隐式的变量可以用来访问环境变量,POM信息,和Maven Settings

env
env变量,暴露了你操作系统或者shell的环境变量。便 如在Maven POM中一个对${env.PATH}的引用将会被${PATH}环境变量替换,在Windows中为%PATH%.

projetc
project变量暴露了POM。可以使用点标记(.)的路径来引用POM元素的值。例如
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>org.sonatype.mavenbook</groupId>
<artifactId>project-a</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>jar</packaging>
<build>
<finalName>${project.groupId}-${project.artifactId}</finalName>
</build>
</project>
当你使用mvn help:effective-pom 查看时,你会看到<finalName>org.sonatype.mavenbook-project-a</finalName>

${basedir} 项目根目录
${project.build.directory} 构建目录,缺省为target
${project.build.outputDirectory} 构建过程输出目录,缺省为target/classes
${project.build.finalName} 产出物名称,缺省为${project.artifactId}-${project.version} 打包版本
${project.packaging} 打包类型,缺省为jar
${project.xxx} 当前pom文件的任意节点的内容

settings
settings变量暴露了Maven settings信息。可以使用点标记(.)的路径来引用settings.xml文件中元素的值。例如${settings.offline}会引用~/.m2/settings.xml文件中offline元素的值。
展开阅读全文

没有更多推荐了,返回首页