范围为“import”和没有“import”的“pom”类型依赖有什么区别？

您只能导入托管依赖项。这意味着您只能将其他 POM 导入到项目 POM 的 dependencyManagement 部分。 IE

...
<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（及其所有子 POM）的 dependency 部分中引用这些依赖项，而不必包含 version 等。

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

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

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

---

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

<dependencyManagement> 部分中 pom 类型依赖项的 import 范围允许您实现 multiple inheritance 的等效项。

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

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

---

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

dependencyManagement 部分仅声明当前项目中的依赖项及其详细信息 - 目的是管理详细信息并在其他项目中重用，通过继承（父级）或导入（范围）。这就像在程序中声明数据类型并使其可供使用。依赖部分定义了项目中依赖的实际使用，可选地继承在dependencyManagment下声明的依赖的细节（即版本等）。这就是为什么如果只将它们放在dependencyManagment 中就会缺少依赖项的原因。这类似于在需要的程序中实例化数据类型的变量实例。

---