在您的Maven-Fu包中增加了一些东西

Apache Maven很简单，但是功能非常强大。使用一些技巧，您可以大大简化和优化您的开发经验。

处理多个非托管模块

假设您有一个主项目A提供了两个实用程序模块foo和bar ，另一个项目B A了foo和bar 。

在使用B ，您意识到需要偶尔对foo和bar进行一些调整。但是，由于它们在不同的项目中，因此通常需要

切换到A
做出改变
mvn install
切换回B
和“刷新”依赖项（如果您使用的是IDE）。

每次都需要进行上游更改。

使用Maven，您可以使用模拟主POM临时“合并”这三部分，该主POM将foo ， bar和B定义为子模块：

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"><modelVersion>4.0.0</modelVersion><!-- blah blah blah --><modules><module>foo</module><module>bar</module><module>B</module></modules>

对我有什么用？

IDE（如IntelliJ IDEA ）会将根标识为多模块项目。这意味着您将能够：

从一个模块无缝浏览到另一个模块。不再需要反编译，字节码不兼容或源映射；在“综合”项目范围内搜索某种类或方法的用法（或重构其中一种方法）时，非常方便。
在同一项目窗口中按需修改每个模块的源和资源。 IDE将自动重新编译所做的更改，并将所有内容添加到运行时类路径中。方便进行带热重装的IDE测试和调试。
版本无缝。如果这三个模块位于不同的VCS根目录下，则IDEA（如IDEA）将分别跟踪每个存储库。如果您提交了一组更改，则每个存储库都会有一个新的提交，以反映其自己的更改部分；都带有相同的消息！

同时，如果构建了根模块，那么普通的Maven将按照适当的顺序构建foo / bar和B （如果需要），这正是我们想要的。

相对路径，FTW！

即使模块分散在整个文件系统中，Maven仍可以通过相对路径轻松解决它们：

<modules><module>../foo</module><module>grandpa/papa/bar</module><module>../../../../../media/disk2/repos/top-secret/B</module></modules>

放下那

也许最常用（因此最被滥用 ）的Maven命令是：

mvn clean install

在您对项目进行一些更改后，事实上的事实便会运行。

而且，在大多数情况下，这简直是过分杀伤力。

从头开始？

该命令结合了两个生命周期阶段 – Maven构建过程的“阶段”。阶段具有确定的顺序；因此，如果您请求某个阶段运行，则其生命周期中的所有先前阶段都将在此阶段之前运行。但是，如果Maven插件发现自己无事可做，那么他们就足够聪明地跳过工作。例如，如果编译的类是最新的，则不会进行编译。

现在， clean不再是默认生命周期的一部分；而是通过删除整个target目录从头开始。另一方面， install几乎快结束了（就在默认生命周期中进行deploy之前）。

mvn clean install将同时运行这两个阶段；而且，由于clean ， 介于两者之间的所有事物也同样如此 。

当您想要清理所有内容并最终将最新的工件安装到本地 Maven存储库中时，它很方便。但是在大多数情况下，您并不需要所有这些。

此外， install最终会使您的本地Maven缓存混乱；特别是如果您经常使用MB或GB大小的捆绑包进行快照/发布。

只做必要的事情！

如果您更新了一个源文件，并希望将其传播到target/classes目录：

mvn compile

Maven将自动检测任何更改–如果没有更改，则完全跳过编译。

如果更改是在测试类或资源中：

mvn test-compile

将其放入target/test-classes 。

只是为了运行测试（它将自动编译任何脏的源代码/测试类）：

mvn test

要获得target最终捆绑包的副本：

mvn package

由于您可能经常要在包装之前先从干净的表盘开始：

mvn clean package

同样，只需指定结束阶段即可；或同时包含开始和结束目标（如果要在某种程度上保持清洁）。您将节省大量时间，处理能力和脾气。

同时在生产中…

如果您当前的版本可以投入生产，只需忘记上面的大部分内容即可；）

mvn clean package

虽然任何“子命令”在理论上都应该做同样的事情，但是您不想冒险；）

虽然我使用上面的package ，但从某种意义上说， install也会更好。因为这样您将在.m2/repository中拥有生产工件的副本–如果丢失了已交付/部署的副本，则可能会节省很多时间。

`--no-snapshot-updates`

如果您仔细观察了一个涉及快照依赖项的构建，您会发现它花了几秒钟的时间来搜索快照的Maven元数据文件（并最终以警告告终；除非您习惯于将快照工件发布到远程）。

如果您还本地建立快照依赖关系，那么通常这没有用，因此可以通过--no-snapshot-updates或-nsu参数禁用元数据检查（和快照同步尝试）。

当然， -o将阻止所有远程同步；但是如果您确实想提取某些依赖项，则不能使用它，在这种情况下， -nsu会有所帮助。

您可以跳过编译！

像（著名的） -Dmaven.test.skip –或-DskipTests ，您可以通过-Dmaven.main.skip跳过编译步骤（即使代码有所更改）。当您只想运行测试而无需花费编译开销时，非常方便；当然，如果您知道这些内容已经被编译。就像-DskipTests一样-但是-DskipTests ！

（对此SO帖子表示敬意）

延续：

您可能已经知道，如果模块在构建过程中发生故障，则可以通过-rf :module-name参数从该点恢复构建。

此参数也可以立即使用。它不仅限于故障场景。如果您有30个模块，但是只想构建最后5个模块，则可以使用-rf :name-of-26th-module 。

美味的测试技巧

继承测试

通常，Maven工件不包括测试类/资源。但是在某些情况下，您希望将一些基本测试类继承到子模块中。使用测试罐说明符，您可以继承仅包含测试类和资源的工件：

<dependency><groupId>com.acme</groupId><artifactId>foo</artifactId><version>3.2.1</version><type>test-jar</type><scope>test</scope></dependency>

“从属”模块上的相应构建配置如下：

<build><plugins><plugin><groupId>org.apache.maven.plugins</groupId><artifactId>maven-jar-plugin</artifactId><executions><execution><goals><goal>test-jar</goal></goals></execution></executions></plugin></plugins></build>

一个警告是，在此过程中不会继承可传递测试依赖项，而必须在每次使用测试JAR时再次手动指定它们。（至少我没有遇到更好的选择。）

如果您正在处理一个测试用例，请不要全部运行。

-Dtest=com.acme.my.pkg.Test可以单独进行WIP测试，因此可以节省大量时间。

根据您的测试运行程序， -Dtest 也可能支持通配符选择器。

当然，您可以临时修改测试插件配置的或数组（例如SureFire ）以限制可运行测试的集合。

调试它

调试Maven测试？

如果您的测试运行程序（例如SureFire）允许您自定义用于测试的命令行或JVM参数，则可以轻松地将派生的JVM配置为在测试开始执行之前等待调试器：

<build><pluginManagement><plugins><plugin><groupId>org.apache.maven.plugins</groupId><artifactId>maven-surefire-plugin</artifactId><!-- ... --><configuration><argLine>-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,address=8000</argLine>

调试Maven本身？

如果您正在编写或对Maven插件或扩展进行故障排除，则在调试模式下运行Maven本身会很方便。

Maven最终是Java，因此您可以简单地调用调用时运行的最终命令，然后使用-Xdebug …params重新运行它。

但是Maven已经有了一个更酷的mvnDebug命令，可以自动为您执行此操作。它的语法与mvn相同，因此非常容易习惯。

调用后，默认情况下它将在端口8000上侦听调试器，并在连接一个端口后立即开始执行；并在断点处停止，显示内部状态，允许表达式求值等。

看日志！！！

这是值得的，因为我们非常善于忽略事物-就在眼前。

就在一开始

我敢打赌，在构建开始时，Maven会有95％的机会喷出至少一个[WARNING] 。虽然我们几乎总是忽略或“推迟”它们，但它们会在将来的某个时刻咬人。

即将结束

如果出现编译，测试或其他故障，Maven将尝试通过转储上下文（stacktraces， [ERROR]等）来提供帮助。有时，您需要向后滚动一到两页才能找到实际的内容，因此，不要在第一次尝试时就放弃并砸在脸上。

最近，我花了将近一个小时的时间来弄清楚-rf :原因-rf : 'd build失败；从头开始时，同一件事成功了。最后，它systemPath关于systemPath依赖项解决错误的两行[WARNING]小systemPath 。就在我眼前，却如此无形。

绝望的时光

在某些情况下，标准的Maven输出无法查明问题，在跟踪模式（ -X ）中运行Maven是最佳做法。尽管其输出可能令人生畏，但它包含Maven（以及您）在构建过程中需要了解的所有内容。插件版本，编译/测试依赖树，外部命令调用（例如测试）；这样您就可以深入挖掘并找到罪魁祸首。

一如既往，耐心是一种美德。

最后的话

就像使用Maven一样，

知道你在做什么。
知道你真正想做什么。
相信Maven可以做到 ，除非另有证明；）

翻译自: https://www.javacodegeeks.com/2018/11/additions-bag-maven-fu.html