在一个多模块的maven项目中，我可以根据另一个模块的DependencyReducedPom做一个模块来计算传递依赖吗? [英] In a multi-module maven project, can I make a module to calculate transitive dependencies based on the DependencyReducedPom of another module?

问题描述

这似乎是一个简单的问题，但由于 maven 极其严格的生命周期和阶段范式，我发现这很困难:

This appears to be a simple question but I found it difficult due to maven's extremely rigorous paradigm of lifecycles and phases:

假设在一个多模块的 maven 项目中，在各个阶段使用了几个插件来将 pom.xml 重写为更有效的版本，值得注意的例子是:

Assuming that in a multi-module maven project, several plugins are used in various phases to rewrite the pom.xml to more effective versions, notable examples are:

• maven-shade-plugin(如果 已启用):当需要发布着色的 uber-jar 时，插件可以摆脱不需要的依赖项被包括.始终在打包阶段执行.

• maven-shade-plugin (if <createDependencyReducedPom> is enabled): when the shaded uber-jar needs to be published, the plugin can shrug off dependencies that doesn't need to be included. ALWAYS execute in package phase.

flatten-maven-plugin:通过将属性引用替换为其实际值，允许模块发布的 pom.xml 不再依赖于父级的 pom.可以在任何阶段执行，但为了保持与 maven-shade-plugin 的互操作性，它也被限制在包阶段(参见 https://issues.apache.org/jira/browse/MSHADE-323)

flatten-maven-plugin: allows module's published pom.xml to be no longer depending on parent's pom, by replacing property references with their actual values. Can be executed in any phase, but to maintain interoperability with maven-shade-plugin it is also confined to package phase (see https://issues.apache.org/jira/browse/MSHADE-323)

当它们与其他模块结合时，maven reactor 构建引擎似乎经常摸索使用哪个版本的重写 pom 来计算传递依赖.理想情况下，应使用打包阶段后的最终版本.但是在最新的 maven 版本 (3.6.3) 中，它只能在重写之前使用 pom.xml，并且没有减少依赖项 &未正确替换所有属性.

When they are combined with other modules, It appears that maven reactor build engine frequently fumbles with which version of the rewritten pom to be used to calculate transitive dependency. Ideally, the final version after package phase should be used. But in the latest maven version (3.6.3) it is only capable of using the pom.xml BEFORE both rewritting, with no reduced dependencies & all properties not replaced properly.

我的问题是:

1. 这个设计有什么意义?当所有插件都明确替换它时，为什么要使用半生不熟的 pom.xml?

1. What's the point of this design? Why using a half-baked pom.xml when all plugins explicitly replaced it?

如何覆盖此行为，以便始终生成和使用 pom.xml 的最终版本，而不管请求的 Maven 目标如何?

How to override this behaviour such that the final version of pom.xml is always generated and used, regardless of the maven goal being requested?

更新 1:目前我正在使用一个简单的规避方法:

UPDATE 1: For the moment I'm using a simple circumvention by:

• 将第一个模块拆分为一个独立的 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 相关讨论)

• splitting the first module into an independent maven project, with both maven-shade and flatten-maven plugin invoked at package phase. (I have no direct evidence but I suspect this is how repackaged dependencies like spark-project.hive https://mvnrepository.com/artifact/org.spark-project.hive/hive-common was made, see https://issues.apache.org/jira/browse/SPARK-20202 for relevant discussion)

使用shell脚本依次编译/发布上述项目和主多模块项目.

use a shell script to compile/publish the above project and the main multi-module project sequentially.

我不是 shell 脚本的忠实粉丝，我认为这违背了 JVM 社区所珍视的与平台无关的壮举.所以如果你有更好的解决方案，请在这里发布，我会根据受欢迎程度接受它.

I'm not a big fan of the shell script, and I think this betrayed the platform-agnostic feat which the JVM community cherished. So if you have a better solution, please post here and I will accept it based on popularity.

非常感谢您的意见

推荐答案

第一件事是:maven 极其严格的生命周期和阶段范式:那些生命周期和阶段有很好的理由.

The first thing is: maven's extremely rigorous paradigm of lifecycles and phases: those lifecycles and phases have very good reasons.

另外你提到几个插件重写了 pom.xml 文件.唯一的例子是 maven-shade-plugin 和 flatten-maven-plugin 正如你所提到的.

Furthermore you mentioned that several plugins rewrite pom.xml file. The only examples are maven-shade-plugin and flatten-maven-plugin as you mentioned.

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

Apart from that as you mentioned maven-shade-plugin intention:

此插件提供了将工件打包到 uber-jar 中的功能，包括其依赖项和遮蔽 - 即重命名 - 某些依赖项的包.

This plugin provides the capability to package the artifact in an uber-jar, including its dependencies and to shade - i.e. rename - the packages of some of the dependencies.

目的是隐藏依赖关系(解压罐子并重新打包成一个罐子)并制作一个可执行的罐子(这也可以通过 maven-assembly-plugin) ......不要耸耸肩.

The intention is to shade the dependencies (unpack the jars and repackage into a single jar) and make an executable jar (this can also being done with the maven-assembly-plugin) of it...not to shrug off dependencies.

flatten-maven-plugin 的想法是删除 pom 文件中不需要供以后使用的部分(构建 POM 与消费者 POM).目前这部分将成为 Maven Core 与 Maven 3.7.0 的一部分......这是分离 构建 pom 和消费者 pom.

The idea of flatten-maven-plugin is to remove parts of a pom file which are not needed for later consumption(Build POM vs. Consumer POM). Currently this part will become part of Maven Core with Maven 3.7.0... This is a big first step to separate build pom and the consumer pom.

那么让我们来看看反应堆构建引擎，它旨在根据依赖关系定义构建顺序.

So let us come to the point of the reactor build engine which is designed to define the order of build based on dependencies.

理想情况下，应使用打包阶段后的最终版本

Ideally, the final version after package phase should be used

所以这意味着在包之前和包之后的阶段(对于此类插件的每次执行)之间具有不同的顺序和不同的依赖关系(包括传递依赖关系).这将导致不可重复的结果.除了重新计算整个依赖树等

So that would mean to have different orders and different dependencies (including transitive dependencies) between the phases before package and after package (for each execution of such plugin). This would result in non repeatable results. Apart from things to recalculate the whole dependency tree etc.

但是在最新的 maven 版本 (3.6.3) 中，它只能在重写之前使用 pom.xml，并且没有减少依赖项 &未正确替换所有属性.

But in the latest maven version (3.6.3) it is only capable of using the pom.xml BEFORE both rewritting, with no reduced dependencies & all properties not replaced properly.

这也适用于所有以前的版本.此外，在构建的最开始读取 pom.xml...

This is also true for all previous versions as well. Furthermore the pom.xml is read at the very beginning of the build...

这个设计有什么意义?当所有插件都明确替换它时，为什么要使用半生不熟的 pom.xml?

What's the point of this design? Why using a half-baked pom.xml when all plugins explicitly replaced it?

你到底想知道什么?还只提到了两个具有不同意图的插件(而不是所有插件).

What exactly would you like to know? Also mentioned only two plugins (and not all plugins) with different intentions.

如何覆盖此行为，以便始终生成和使用 pom.xml 的最终版本，而不管请求的 Maven 目标如何?

How to override this behaviour such that the final version of pom.xml is always generated and used, regardless of the maven goal being requested?

没有选项可以覆盖此行为，因为它不存在.这意味着要重写大部分 Maven 核心.

There is no option to override this behaviour cause it does not exist. This would mean to rewrite large parts of Maven core.

这篇关于在一个多模块的maven项目中，我可以根据另一个模块的DependencyReducedPom做一个模块来计算传递依赖吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！