作为开发利器的maven,为我们提供了十分丰富的命令,了解maven的命令行操作并熟练运用常见的maven命令还是十分必要的。无论多先进多炫的图形化界面,底层都得靠maven命令来驱动。知其然,知其所以然,方能百战不殆。
1,常用参数整理。
常用命令参数汇总整理:
命令参数 | 备注 |
mvn -v | —version 显示版本信息 |
mvn -V | –show-version 显示版本信息后继续执行Maven其他目标; |
mvn -h | –help 显示帮助信息; |
mvn -e | –errors 控制Maven的日志级别,产生执行错误相关消息; |
mvn -X | –debug 控制Maven的日志级别,产生执行调试信息; |
mvn -q | –quiet 控制Maven的日志级别,仅仅显示错误; |
mvn -Pxxx | 激活 id 为 xxx的profile (如有多个,用逗号隔开); |
mvn -Dxxx=yyy | 指定Java全局属性; |
mvn -o | –offline 运行offline模式,不联网更新依赖; |
mvn -N | —non-recursive 仅在当前项目模块执行命令,不构建子模块; |
mvn -pl | –module_name 在指定模块上执行命令; |
mvn -ff | –fail-fast 遇到构建失败就直接退出; |
mvn -fn | –fail-never 无论项目结果如何,构建从不失败; |
mvn -fae | –fail-at-end 仅影响构建结果,允许不受影响的构建继续; |
mvn -C | –strict-checksums 如果校验码不匹配的话,构建失败; |
mvn -c | –lax-checksums 如果校验码不匹配的话,产生告警; |
mvn -U | 强制更新snapshot类型的插件或依赖库(否则maven一天只会更新一次snapshot依赖); |
mvn -npu | –no-plugin-s 对任何相关的注册插件,不进行最新检查(使用该选项使Maven表现出稳定行为,该稳定行为基于本地仓库当前可用的所有插件版本); |
mvn -cpu | –check-plugin-updates 对任何相关的注册插件,强制进行最新检查(即使项目POM里明确规定了Maven插件版本,还是会强制更新); |
mvn -up | –update-plugins [mvn -cpu]的同义词; |
mvn -B | –batch-mode 在非交互(批处理)模式下运行(该模式下,当Mven需要输入时,它不会停下来接受用户的输入,而是使用合理的默认值); |
mvn -f | –file <file> 强制使用备用的POM文件; |
mvn -s | –settings <arg> 用户配置文件的备用路径; |
mvn -gs | –global-settings <file> 全局配置文件的备用路径; |
mvn -emp | –encrypt-master-password <password> 加密主安全密码,存储到Maven settings文件里; |
mvn -ep | –encrypt-password <password> 加密服务器密码,存储到Maven settings文件里; |
mvn -npr | –no-plugin-registry 对插件版本不使用~/.m2/plugin-registry.xml(插件注册表)里的配置; |
2,其他参数介绍。
1. -D 传入属性参数
比如命令:
mvn package -Dmaven.test.skip=true
以“-D”
开头,意思是将“maven.test.skip”
的值设为“true”
,就是告诉maven打包的时候跳过单元测试。同理,“mvn deploy -Dmaven.test.skip=true
”代表部署项目并跳过单元测试。
2. -P 使用指定的Profile配置
比如项目开发需要有多个环境,一般为开发,测试,预发,正式4个环境,在pom.xml中的配置如下:
<profiles> <profile> <id>dev</id> <properties> <env>dev</env> </properties> <activation> <activeByDefault>true</activeByDefault> </activation> </profile> <profile> <id>qa</id> <properties> <env>qa</env> </properties> </profile> <profile> <id>pre</id> <properties> <env>pre</env> </properties> </profile> <profile> <id>prod</id> <properties> <env>prod</env> </properties> </profile> </profiles> ...... <build> <filters> <filter>config/${env}.properties</filter> </filters> <resources> <resource> <directory>src/main/resources</directory> <filtering>true</filtering> </resource> </resources> ...... </build>
profiles定义了各个环境的变量id,filters中定义了变量配置文件的地址,其中地址中的环境变量就是上面profile中定义的值,resources中是定义哪些目录下的文件会被配置文件中定义的变量替换。
通过maven可以实现按不同环境进行打包部署,命令为:
mvn package -P dev
其中“dev
“为环境的变量id
,代表使用Id为“dev”的profile。
3,maven的使用。
我们已经知道maven预定义了许多的阶段(phase),每个插件都依附于这些阶段,并且在进入某个阶段的时候,调用运行这些相关插件的功能。我们先来看完整的maven生命周期:
生命周期:
生命周期 | 阶段描述 |
validate | 验证项目是否正确,以及所有为了完整构建必要的信息是否可用 |
generate-sources | 验证项目是否正确,以及所有为了完整构建必要的信息是否可用 |
process-sources | 处理源代码,比如过滤一些值 |
generate-resources | 生成所有需要包含在打包过程中的资源文件 |
process-resources | 复制并处理资源文件至目标目录,准备打包 |
compile | 编译项目的源代码 |
process-classes | 后处理编译生成的文件,例如对Java类进行字节码增强(bytecode enhancement) |
process-classes | 生成所有包含在测试编译过程中的测试源码 |
process-test-sources | 处理测试源码,比如过滤一些值 |
process-test-sources | 生成测试需要的资源文件 |
process-test-resources | 复制并处理测试资源文件至测试目标目录 |
process-test-resources | 编译测试源码至测试目标目录 |
test | 使用合适的单元测试框架运行测试。这些测试应该不需要代码被打包或发布 |
prepare-package | 在真正的打包之前,执行一些准备打包必要的操作。这通常会产生一个包的展开的处理过的版本(将会在Maven 2.1+中实现) |
package | 将编译好的代码打包成可分发的格式,如JAR,WAR,或者EAR |
pre-integration-test | 执行一些在集成测试运行之前需要的动作。如建立集成测试需要的环境 |
integration-test | 如果有必要的话,处理包并发布至集成测试可以运行的环境 |
integration-test | 执行一些在集成测试运行之后需要的动作。如清理集成测试环境 |
verify | 执行所有检查,验证包是有效的,符合质量规范 |
install | 执行所有检查,验证包是有效的,符合质量规范 |
deploy | 复制最终的包至远程仓库,共享给其它开发人员和项目(通常和一次正式的发布相关) |
4,maven的核心插件介绍。
maven核心的插件列表可以参考http://maven.apache.org/plugins/index.html 。这里仅列举几个常用的插件及其配置参数:
clean插件
compiler插件
surefire插件
jar
war
resources
install
deploy
site
参考如下地址并整理:
https://blog.csdn.net/makyan/article/details/51723294
https://blog.csdn.net/u012152619/article/details/51473410#
http://www.cnblogs.com/951106Nancy/p/9355448.html
