在一个多模块的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 核心的大部分内容。