Apache Maven很簡單，但是功能非常強大。 使用一些技巧，您可以大大簡化和優(yōu)化您的開發(fā)經(jīng)驗。

處理多個非托管模塊

假設(shè)您有一個主項目A提供了兩個實用程序模塊foo和bar ，另一個項目B A了foo和bar 。

在使用B ，您意識到需要偶爾對foo和bar進行一些調(diào)整。 但是，由于它們在不同的項目中，因此通常需要

• 切換到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 ）會將根標識為多模塊項目。 這意味著您將能夠：

• 從一個模塊無縫瀏覽到另一個模塊。 不再需要反編譯，字節(jié)碼不兼容或源映射 ； 在“綜合”項目范圍內(nèi)搜索某種類或方法的用法（或重構(gòu)其中一種方法）時，非常方便。
• 在同一項目窗口中按需修改每個模塊的源和資源。 IDE將自動重新編譯所做的更改，并將所有內(nèi)容添加到運行時類路徑中。 方便進行帶熱重裝的IDE測試和調(diào)試。
• 版本無縫。 如果這三個模塊位于不同的VCS根目錄下，則IDEA（如IDEA）將分別跟蹤每個存儲庫。 如果您提交了一組更改，則每個存儲庫都會有一個新的提交，以反映其自己的更改部分； 都帶有相同的消息！

同時，如果構(gòu)建了根模塊，那么普通的Maven將按照適當?shù)捻樞驑?gòu)建foo / bar和B （如果需要），這正是我們想要的。

相對路徑，FTW！

即使模塊分散在整個文件系統(tǒng)中，Maven仍可以通過相對路徑輕松解決它們：

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

放下那

也許最常用（因此最被濫用 ）的Maven命令是：

mvn clean install

在您對項目進行一些更改后，事實上的事實便會運行。

而且，在大多數(shù)情況下，這簡直是過分殺傷力。

從頭開始？

該命令結(jié)合了兩個生命周期階段 – Maven構(gòu)建過程的“階段”。 階段具有確定的順序； 因此，如果您請求某個階段運行，則其生命周期中的所有先前階段都將在此階段之前運行。 但是，如果Maven插件發(fā)現(xiàn)自己無事可做，那么他們就足夠聰明地跳過工作。 例如，如果編譯的類是最新的，則不會進行編譯。

現(xiàn)在， clean不再是默認生命周期的一部分； 而是通過刪除整個target目錄從頭開始。 另一方面， install幾乎快結(jié)束了（就在默認生命周期中進行deploy之前）。

mvn clean install將同時運行這兩個階段； 而且，由于clean ， 介于兩者之間的所有事物也同樣如此 。

當您想要清理所有內(nèi)容并最終將最新的工件安裝到本地 Maven存儲庫中時，它很方便。 但是在大多數(shù)情況下，您并不需要所有這些。

此外， install最終會使您的本地Maven緩存混亂； 特別是如果您經(jīng)常使用MB或GB大小的捆綁包進行快照/發(fā)布。

只做必要的事情！

如果您更新了一個源文件，并希望將其傳播到target/classes目錄：

mvn compile

Maven將自動檢測任何更改–如果沒有更改，則完全跳過編譯。

如果更改是在測試類或資源中：

mvn test-compile

將其放入target/test-classes 。

只是為了運行測試（它將自動編譯任何臟的源代碼/測試類）：

mvn test

要獲得target最終捆綁包的副本：

mvn package

由于您可能經(jīng)常要在包裝之前先從干凈的表盤開始：

mvn clean package

同樣，只需指定結(jié)束階段即可； 或同時包含開始和結(jié)束目標（如果要在某種程度上保持清潔）。 您將節(jié)省大量時間，處理能力和脾氣。

同時在生產(chǎn)中…

如果您當前的版本可以投入生產(chǎn)，只需忘記上面的大部分內(nèi)容即可；）

mvn clean package

雖然任何“子命令”在理論上都應(yīng)該做同樣的事情，但是您不想冒險；）

雖然我使用上面的package ，但從某種意義上說， install也會更好。 因為這樣您將在.m2/repository中擁有生產(chǎn)工件的副本–如果丟失了已交付/部署的副本，則可能會節(jié)省很多時間。

更多跳過…

--no-snapshot-updates

如果您仔細觀察了一個涉及快照依賴項的構(gòu)建，您會發(fā)現(xiàn)它花了幾秒鐘的時間來搜索快照的Maven元數(shù)據(jù)文件（并最終以警告告終；除非您習(xí)慣于將快照工件發(fā)布到遠程）。

如果您還本地建立快照依賴關(guān)系，那么通常這沒有用，因此可以通過--no-snapshot-updates或-nsu參數(shù)禁用元數(shù)據(jù)檢查（和快照同步嘗試）。

當然， -o將阻止所有遠程同步； 但是如果您確實想提取某些依賴項，則不能使用它，在這種情況下， -nsu會有所幫助。

您可以跳過編譯！

像（著名的） -Dmaven.test.skip –或-DskipTests ，您可以通過-Dmaven.main.skip跳過編譯步驟（即使代碼有所更改）。 當您只想運行測試而無需花費編譯開銷時，非常方便； 當然，如果您知道這些內(nèi)容已經(jīng)被編譯。 就像-DskipTests一樣-但是-DskipTests ！

（ 對此SO帖子表示敬意）

延續(xù)：

您可能已經(jīng)知道，如果模塊在構(gòu)建過程中發(fā)生故障，則可以通過-rf :module-name參數(shù)從該點恢復(fù)構(gòu)建。

此參數(shù)也可以立即使用。 它不僅限于故障場景。 如果您有30個模塊，但是只想構(gòu)建最后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>

“從屬”模塊上的相應(yīng)構(gòu)建配置如下：

<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測試，因此可以節(jié)省大量時間。

根據(jù)您的測試運行程序， -Dtest 也可能支持通配符選擇器 。

當然，您可以臨時修改測試插件配置的或數(shù)組（例如SureFire ）以限制可運行測試的集合。

調(diào)試它

調(diào)試Maven測試？

如果您的測試運行程序（例如SureFire）允許您自定義用于測試的命令行或JVM參數(shù)，則可以輕松地將派生的JVM配置為在測試開始執(zhí)行之前等待調(diào)試器 ：

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

調(diào)試Maven本身？

如果您正在編寫或?qū)aven插件或擴展進行故障排除，則在調(diào)試模式下運行Maven本身會很方便。

Maven最終是Java，因此您可以簡單地調(diào)用調(diào)用時運行的最終命令，然后使用-Xdebug …params重新運行它。

但是Maven已經(jīng)有了一個更酷的mvnDebug命令，可以自動為您執(zhí)行此操作。 它的語法與mvn相同，因此非常容易習(xí)慣。

調(diào)用后，默認情況下它將在端口8000上偵聽調(diào)試器，并在連接一個端口后立即開始執(zhí)行； 并在斷點處停止，顯示內(nèi)部狀態(tài)，允許表達式求值等。

看日志！！！

這是值得的，因為我們非常善于忽略事物-就在眼前。

就在一開始

我敢打賭，在構(gòu)建開始時，Maven會有95％的機會噴出至少一個[WARNING] 。 雖然我們幾乎總是忽略或“推遲”它們，但它們會在將來的某個時刻咬人。

即將結(jié)束

如果出現(xiàn)編譯，測試或其他故障，Maven將嘗試通過轉(zhuǎn)儲上下文（stacktraces， [ERROR]等）來提供幫助。 有時，您需要向后滾動一到兩頁才能找到實際的內(nèi)容，因此，不要在第一次嘗試時就放棄并砸在臉上。

最近，我花了將近一個小時的時間來弄清楚-rf :原因-rf : 'd build失敗； 從頭開始時，同一件事成功了。 最后，它systemPath關(guān)于systemPath依賴項解決錯誤的兩行[WARNING]小systemPath 。 就在我眼前，卻如此無形。

絕望的時光

在某些情況下，標準的Maven輸出無法查明問題，在跟蹤模式（ -X ）中運行Maven是最佳做法。 盡管其輸出可能令人生畏，但它包含Maven（以及您）在構(gòu)建過程中需要了解的所有內(nèi)容。 插件版本，編譯/測試依賴樹，外部命令調(diào)用（例如測試）； 這樣您就可以深入挖掘并找到罪魁禍首。

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

最后的話

就像使用Maven一樣，

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

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

總結(jié)

以上是生活随笔為你收集整理的在您的Maven-Fu包中增加了一些东西的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。