范围为“import”和没有“import”的“pom”类型依赖有啥区别?

Posted

技术标签:

【中文标题】范围为“import”和没有“import”的“pom”类型依赖有啥区别?【英文标题】:What is the difference between "pom" type dependency with scope "import" and without "import"?范围为“import”和没有“import”的“pom”类型依赖有什么区别? 【发布时间】:2012-07-31 11:20:15 【问题描述】:

从 Maven 2.0.9 开始有可能包含

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

&lt;dependencyManagement&gt; 部分。

据我了解,它将被此 pom 中包含的依赖项“替换”,就好像它们最初是在此处定义的一样。

上面的解决方案和没有import范围的简单依赖有什么区别(我看到后者被称为“依赖分组”)?唯一的区别是这种“分组”的依赖关系在解决依赖关系优先级时具有较低的优先级吗?

【问题讨论】:

【参考方案1】:

您只能导入托管依赖项。这意味着您只能将其他 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-iddependencyManagement 部分中定义的所有依赖项都包含在您的POM 的dependencyManagement 部分中。然后,您可以在 POM(及其所有子 POM)的 dependency 部分中引用这些依赖项,而无需包含 version 等。

但是,如果在您的 POM 中您只是简单地定义了对 other-pom-artifact-id 的正常依赖项,那么来自 other-pom-artifact-iddependency 部分的所有 dependencies 都将传递地包含在您的项目中 - 但是在 dependencyManagement 中定义的依赖项other-pom-artifact-id 的部分根本不包括在内。

所以基本上两种不同的机制用于导入/包含两种不同类型的依赖项(托管依赖项和正常依赖项)。

maven 网站上有一个很好的页面,它可以比我解释得更好,Dependency Management in Maven,它还包含importing dependencies 的具体信息。

【讨论】:

如果pom A in 是pom B 的父级,你能把B 放在项目A 的依赖管理中,范围为import吗? 很好的答案来解释它是如何工作的,但为什么呢?为什么你不想传递地包含其他依赖项?你也可以两者都做吗?导入 other-pom-artifact-id 然后将 other-pom-artifact-id 声明为依赖项? 一篇关于 DZone 的文章陈述了不同的情况:... &lt;dependencies&gt; &lt;dependency&gt; &lt;groupId&gt;$project.groupId&lt;/groupId&gt; &lt;artifactId&gt;pomlib-lib&lt;/artifactId&gt; &lt;type&gt;pom&lt;/type&gt; &lt;scope&gt;import&lt;/scope&gt; &lt;/dependency&gt; &lt;dependency&gt; &lt;groupId&gt;$project.groupId&lt;/groupId&gt; &lt;artifactId&gt;pomlib-war&lt;/artifactId&gt; &lt;type&gt;war&lt;/type&gt; &lt;/dependency&gt; &lt;/dependencies&gt; &lt;/project&gt;DRY and Skinny War @JunchenLiu :假设您只使用了项目 A 的几个功能,因此您可以选择仅包含该功能所需的传递依赖项。您也可以通过在 中使用 来解决这个问题。例如结帐:jdbi.org/#_getting_started【参考方案2】:

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

importpom 类型依赖的范围&lt;dependencyManagement&gt; 部分允许您实现multiple inheritance 的等效项。

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

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

【讨论】:

你确定吗?我已将常规 pom(具有自己的依赖项)作为其他项目(打包战争)中的常规依赖项,并将 pom 项目的所有依赖项包含在目标项目的 WEB-INF/lib 中。这就是我问这个问题的原因:) 感谢@Raghuram,在回答问题时完全忘记提及父 POM 选项。至于将 pom 类型的项目作为简单的依赖项,这是可能的。如原始问题中所述,它可用于group dependencies Working link about group dependencies【参考方案3】:

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

    dependencyManagement 部分仅声明当前项目中的依赖项及其详细信息 - 目的是管理详细信息并在其他项目中重用,或者通过继承( 父级)或导入(范围)。这就像在程序中声明数据类型并使其可供使用。

    dependency部分定义了依赖项在项目中的实际使用,可选继承声明的依赖项的详细信息(即版本等) dependencyManagment 下。这就是为什么如果您只将它们放在 dependencyManagment 中,您将缺少依赖项。这类似于在需要的程序中实例化数据类型的变量实例。

【讨论】:

这很好也很清楚,但它回答了与上述问题不同的问题。 :-)

以上是关于范围为“import”和没有“import”的“pom”类型依赖有啥区别?的主要内容,如果未能解决你的问题,请参考以下文章

匿名对象

oc59--匿名分类

export ,export default 和 import 区别 以及用法

export ,export default 和 import 区别 以及用法

随机模块(import random)

@enable跟@import注解