3.示例

1）创建项目

mvn archetype:generate -DarchetypeCatalog=internal -DgroupId=com.yy.testweb1 -DartifactId=testweb1 -DarchetypeArtifactId=maven-archetype-quickstart -DpackageName=com.yy.testweb1 -Dversion=1.0

archetype:generate 目标传入了 version参数。它覆写了默认值 1.0-SNAPSHOT

2）添加组织，法律和开发人员信息

3）项目依赖

如果你需要找出 classpath 中有什么，你可以使用 Maven Dependency 插 件来打印出已解决依赖的列表

mvn dependency:resolve

如果你想知道你项目的整个依赖树

mvn dependency:tree

如果想要查看完整的依赖踪迹，包含那些因为冲突或者其它原因而被拒绝引入的构件

mvn install -X   (-X开启调试输出，打印debug日志)

依赖一个包，其中scope依赖范围代表，在一般的编译和运行时都不需要，它们只有在测试编译和测试运行阶段可用。

 <dependency><groupId>org.apache.commons</groupId><artifactId>commons-io</artifactId><version>1.3.2</version><scope>test</scope></dependency>

4）单元测试

mvn test

test阶段是 Maven 生命周期中常规的一部分，如果想要运行到 test阶段为止的所有生命周期阶段，运行 mvn test。

如果你的测试失败了，你可以去/target/surefire-reports目录查看，里面有你单元测试生成的异常堆栈信息和错误信息。如果想运行系统中的test并且忽略掉失败的则可以使用：

mvn test -Dmaven.test.failure.ignore=true

运行 mvn package或者 mvn install的时候也会运行到test，如果不想运行test，则添加 -Dmaven.test.skip=true （mvn package -Dmaven.test.skip=true）另外package是把jar打到本项目的target下，而install时把target下的jar安装到本地仓库，供其他项目使用。deploy 是上传到远程仓库。

5）配置插件

创建web项目：mvn archetype:generate -DarchetypeCatalog=internal -DgroupId=com.yy.testweb2 -DartifactId=testweb2 -DarchetypeArtifactId=maven-archetype-webapp

增加插件，定义打包名称，注意此处插件开发者提供了默认值，如果需要自定义一些属性，则需加入configuration元素

运行插件启动项目 ：mvn jetty:run

访问：http://localhost:8080/testweb2/

6）多模块构建

多模块时需要提出单独parent项目，它仅仅是一个引用其它Maven项目的POM，并且打包结果为pom共子项目引用。

当Maven执行一个带有子模块的项目的时候，Maven首先载入父POM，然后定位所有的子模块POM。Maven然后将所有这些项目的POM放入到一个称为Maven 反应堆（Reactor）的东西中，由它负责分析模块之间的依赖关系。这个反应堆处理组件的排序，以确保相互独立的模块能以适当的顺序被编译和安装。

7）pom优化

优化一个多模块项目的POM，寻找一个POM中的重复，或者多个兄弟POM中的重复。企业级项目中创建的不同POM，就会注意到几种重复模式。第一种重复模式是：一些依赖如spring和在多个模块中被声明。第二种重复模式是：有一些依赖是关联的，共享同样的版本，比如log4j2。

第一种重复使用dependencyManagement解决，将共同依赖放入parent的dependencyManagement中，子级pom去掉依赖版本和排除配置。

第二种重复在父pom中增加properties，设置版本。

优化插件，使用dependencyManagement在父pom中定义插件，在子pom中直接使用。

使用Maven Dependency插件对pom进行优化，能够发现对于依赖的直接引用

mvn dependency:analyze  

Used undeclared dependencies

该列表列出的是程序代码直接用到的、但并没在pom.xml里定义的依赖项。

Unused declared dependencies

该列表列出的是程序代码没用到的、但在pom.xml里定义的依赖项。注意，该列表可能不准确，因为程序代码可能使用了反射技术，在运行时需要这些jar包存在。

mvn dependency:tree  依赖树

只关心log4j依赖

mvn dependency:tree -Dincludes=log4j:log4j或mvn dependency:tree -Dincludes=*:log4j

一个依赖项可能来自多处，可加上"-Dverbose"参数进行查看

mvn dependency:tree -Dincludes=*:spring-core -Dverbose

使用maven-dependency-plugin对pom.xml文件进行优化

优化的目标是不多不少地定义依赖项。不仅依赖项的个数要不多不少，而且依赖项的作用域也要恰到好处。其验证方法是：

1.检查是否少定义了依赖项，即执行mvn clean dependency:analyze后，应没有Used undeclared dependencies列表。Unused declared dependencies列表中的依赖项需人工判断是否有必要存在，若无必要则请删除。特别地，对于其中的compile和test依赖项，如果不需要或能被其它依赖项传递带出则请删除。检查方法是：先删除该依赖项重试。如果重试成功则保持删除，如果不成功则改为test再重试，如果重试不成功则改为compile。如果你熟悉dependency:tree命令，你也可以从该命令的输出直接看到预期的结果。既然我们的代码没用到那个依赖项，为什么删除该依赖项可能导致编译不通过呢？这可能的原因是我们所依赖的依赖项其本身又依赖了其它依赖项，但它们之间是provided或optional关系，导致不传递依赖。

2.检查是否多定义了依赖项，并检查作用域是否定大了，即执行mvn clean dependency:analyze -Dmaven.test.skip=true后，应没有Used undeclared dependencies列表。上面第一步通过后，这里肯定不会出现该列表。Unused declared dependencies列表中可以含有任意作用域的依赖项。我们需要去检查能否缩小作用域的范围，特别地，需要重点检查compile作用域是否能缩小到test、provided、runtime和system，如果能则改之。

3.以上步骤中如果修改了pom.xml文件，则请回到第一步重新开始验证，以保证优化前能编译通过。

4.执行mvn clean test命令做进一步验证。

https://www.cnblogs.com/yang-wu/p/3262499.html