在一個多模塊的maven項目中，我可以根據另一個模塊的DependencyReducedPom做一個模塊來計算傳遞依賴嗎？

Question

這似乎是一個簡單的問題，但由於 maven 極其嚴格的生命周期和階段范式，我發現這很困難：

假設在一個多模塊 maven 項目中，在各個階段使用了幾個插件將 pom.xml 重寫為更有效的版本，值得注意的例子是：

• maven-shade-plugin（如果啟用了<createDependencyReducedPom> ）：當需要發布着色的 uber-jar 時，插件可以擺脫不需要包含的依賴項。 始終在包階段執行。

• flatten-maven-plugin：通過將屬性引用替換為其實際值，允許模塊發布的 pom.xml 不再依賴於父級的 pom。 可以在任何階段執行，但為了保持與 maven-shade-plugin 的互操作性，它也僅限於包階段（參見https://issues.apache.org/jira/browse/MSHADE-323 ）

當它們與其他模塊結合時，maven reactor 構建引擎似乎經常摸索使用哪個版本的重寫 pom 來計算傳遞依賴。 理想情況下，應使用打包階段后的最終版本。 但是在最新的 maven 版本 (3.6.3) 中，它只能在重寫之前使用 pom.xml，沒有減少依賴項並且所有屬性都沒有正確替換。

我的問題是：

1. 這個設計的意義何在？ 當所有插件都明確替換它時，為什么要使用半生不熟的 pom.xml？

2. 如何覆蓋此行為，以便始終生成和使用 pom.xml 的最終版本，而不管請求的 Maven 目標如何？

更新 1 ：目前我正在使用一個簡單的規避方法：

• 將第一個模塊拆分為一個獨立的 maven 項目，在打包階段調用 maven-shade 和 flatten-maven 插件。 （我沒有直接證據，但我懷疑這就是重新打包依賴項如spark-project.hive https://mvnrepository.com/artifact/org.spark-project.hive/hive-common 的方式，請參閱https://issues .apache.org/jira/browse/SPARK-20202相關討論）

• 使用shell腳本依次編譯/發布上述項目和主多模塊項目。

我不是 shell 腳本的忠實粉絲，我認為這背叛了 JVM 社區所珍視的與平台無關的壯舉。 所以如果你有更好的解決方案，請在這里發布，我會根據受歡迎程度接受它。

非常感謝您的意見

Answer 1

首先是： maven's extremely rigorous paradigm of lifecycles and phases:那些生命周期和階段有很好的理由。

此外你提到幾個插件重寫 pom.xml 文件。 唯一的例子是你提到的maven-shade-plugin和flatten-maven-plugin 。

除此之外，正如您提到的 maven-shade-plugin 意圖：

該插件提供了將工件打包到 uber-jar 中的功能，包括它的依賴項和遮蔽 - 即重命名 - 一些依賴項的包。

目的是隱藏依賴項（將 jar 解包並重新打包到單個 jar 中）並制作一個可執行的 jar（這也可以使用maven-assembly-plugin 完成）……而不是擺脫依賴關系。

flatten-maven-plugin 的想法是刪除 pom 文件中不需要供以后使用的部分（ 構建 POM 與消費者 POM ）。 目前這部分將成為 Maven Core 與 Maven 3.7.0 的一部分......這是分離構建 pom和消費者 pom 的重要第一步。

所以讓我們來看看反應堆構建引擎，它旨在根據依賴關系定義構建順序。

理想情況下，應使用打包階段后的最終版本

所以這意味着在包之前和之后的階段（對於此類插件的每次執行）之間具有不同的順序和不同的依賴關系（包括傳遞依賴關系）。 這將導致不可重復的結果。 除了重新計算整個依賴樹等的事情。

但是在最新的 maven 版本 (3.6.3) 中，它只能在重寫之前使用 pom.xml，沒有減少依賴項並且所有屬性都沒有正確替換。

對於所有以前的版本也是如此。 此外，在構建的最開始讀取 pom.xml ......

這個設計的意義何在？ 當所有插件都明確替換它時，為什么要使用半生不熟的 pom.xml？

你到底想知道什么？ 還只提到了兩個具有不同意圖的插件（而不是所有插件）。

如何覆蓋此行為，以便始終生成和使用 pom.xml 的最終版本，而不管請求的 Maven 目標如何？

沒有選項可以覆蓋此行為，因為它不存在。 這意味着要重寫 Maven 核心的大部分內容。