具有“ import”作用域的“ pom”类型依赖与不具有“ import”作用域的“ pom”类型依赖有什么区别？

从 Maven2.0.9开始，有可能包括

<type>pom</type>
<scope>import</scope>

在 <dependencyManagement>部分。

根据我的理解，它将被“替换”为包含在这个 pom 中的依赖关系，就好像它们最初是在这里定义的一样。

上述解决方案与没有 import作用域(我看到后者被称为“依赖项分组”)的简单依赖关系之间的区别是什么？在解析依赖项优先级时，这种“分组”依赖项的优先级较低，这是唯一的区别吗？

113570 次浏览
小开
最佳答案

只能导入 托管依赖项。这意味着您只能将 进口其他 POM 放入项目 POM 的 dependencyManagement部分。也就是说。

...
<dependencyManagement>
<dependencies>
<dependency>
<groupId>other.pom.group.id</groupId>
<artifactId>other-pom-artifact-id</artifactId>
<version>SNAPSHOT</version>
<scope>import</scope>
<type>pom</type>
</dependency>
</dependencies>
</dependencyManagement>
...

然后发生的情况是，在 other-pom-artifact-id的 dependencyManagement部分中定义的所有依赖项都包含在 POM 的 dependencyManagement部分中。然后，您可以在 POM 的 dependency部分(及其所有子 POM)中引用这些依赖项，而不必包含 version等。

然而，如果在 POM 中您只是简单地定义了一个对 other-pom-artifact-id的普通依赖项，那么 other-pom-artifact-id的 dependency部分中的所有 dependencies都会传递性地包含在您的项目中——然而，在 other-pom-artifact-id的 dependencyManagement部分中定义的依赖项根本就不包括在内。

因此，基本上这两种不同的机制用于导入/包含两种不同类型的依赖项(托管依赖项和普通依赖项)。

在专家网站上有一个很好的页面，它可以比我更好地解释这一点，Maven 中的依赖管理，它也包含了关于 输入依赖项的具体信息。

小开

不能在另一个项目中将 pom类型的项目作为 simple dependency。(嗯，你可以——但它不会做任何有用的事情)。只能存在 parent-child关系。这基本上是 managing dependency through inheritance。

import范围中的 pom类型依赖在 <dependencyManagement>部分允许您实现相当于 multiple inheritance。

你可以有不同的 poms-每个 managing一堆相关的依赖关系。使用它们的项目可以 import这些 poms，然后指定它们需要的依赖关系，而无需担心版本。这基本上是 bill of materials概念，在@DB5指定的链接中进行了说明。

这有助于防止复杂的多模块项目的 parent poms变得过于庞大和笨拙。

小开

两个与面向对象程序设计范式非常相似的概念将有助于回答这个问题:

  1. 依赖性管理部分只声明当前项目中的依赖关系及其细节——目的是管理细节，并通过继承(家长)或导入(范围)在其他项目中重用。这就像在程序中声明数据类型并使其可用一样。

  2. < em > 依赖性 部分定义了依赖项在项目中的实际使用，可以选择继承在 < em > DependencyManagement 下声明的依赖项的细节(例如，版本等)。这就是为什么如果只将依赖项放在 < em > DependencyManagement 中，就会缺少依赖项的原因。这类似于在需要数据类型的程序中实例化数据类型的变量实例。


提交答案