Maven 基础知识大全汇总整理

文章发布较早，内容可能过时，阅读注意甄别。

作为开发利器的 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 仅在当前项目 (opens new window)模块执行命令, 不构建子模块;
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>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

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插件

只包含一个 goal 叫做 clean:clean ，负责清理构建时候创建的文件。默认清理的位置是如下几个变量指定的路径：project.build.directory, project.build.outputDirectory,project.build.testOutputDirectory, and project.reporting.outputDirectory 。

compiler 插件

包含 2 个 goal，分别是 compiler:compile 和 compiler:testCompile 。可以到这里查看两者的具体参数设置：compile , testCompile 。

surefire插件

运行单元测试用例的插件，并且能够生成报表。包含一个 goal 为 surefire:test 。主要参数 testSourceDirectory 用来指定测试用例目录，参考完整用法帮助

jar

负责将工程输出打包到 jar 文件中。包含两个 goal，分别是 jar:jar, jar:test-jar 。两个 goal 负责从 classesDirectory 或 testClassesDirectory 中获取所有资源，然后输出 jar 文件到 outputDirectory 中。

war

负责打包成 war 文件。常用 goal 有 war:war ，负责从 warSourceDirectory（默认 ${basedir}/src/main/webapp）打包所有资源到 outputDirectory 中。

resources

负责复制各种资源文件，常用 goal 有 resources:resources ，负责将资源文件复制到 outputDirectory 中，默认为 ${project.build.outputDirectory}。

install

负责将项目输出 (install:install) 或者某个指定的文件 (install:install-file) 加入到本机库 %USERPROFILE%/.m2/repository 中。可以用 install:help 寻求帮助。

deploy

负责将项目输出 (deploy:deploy) 或者某个指定的文件 (deploy:deploy-file) 加入到公司库中。

site

将工程所有文档生成网站，生成的网站界面默认和 apache 的项目站点类似，但是其文档用 doxia 格式写的，目前不支持 docbook，需要用其他插件配合才能支持。需要指出的是，在 maven 2.x 系列中和 maven3.x 的 site 命令处理是不同的，在旧版本中，用 mvn site 命令可以生成 reporting 节点中的所有报表，但是在 maven3 中，reporting 过时了，要把这些内容作为 maven-site-plugin 的 configuration 的内容才行。详细内容可以参考 http://www.wakaleo.com/blog/292-site-generation-in-maven-3

参考如下地址并整理：

https://blog.csdn.net/makyan/article/details/51723294 https://blog.csdn.net/u012152619/article/details/51473410# http://www.cnblogs.com/951106Nancy/p/9355448.html

上次更新: 2024/06/13, 22:13:45

← tomcat默认日志优化处理会话管理工具tmux整理→