Maven中dependencyManagement和依赖关系之间的区别

dependencyManagement和之间有什么区别dependencies？我已经在Apache Maven网站上看到了这些文档。似乎dependencyManagement可以在其子模块中使用在之下定义的依赖项，而无需指定版本。

例如：

父项目（Pro-par）在以下项下定义依赖项dependencyManagement：

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8</version>
    </dependency>
 </dependencies>
</dependencyManagement>

然后在Pro-par的子级中，我可以使用junit：

  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
    </dependency>
 </dependencies>

但是，我想知道是否有必要在父pom中定义junit吗？为什么不直接在所需的模块中定义它？

依赖关系管理允许整合和集中管理依赖关系版本，而无需添加所有子级都继承的依赖关系。当您有一组项目（即多个项目）继承同一个父对象时，此功能特别有用。

的另一个极其重要的用例dependencyManagement是控制在传递依赖中使用的工件的版本。没有示例就很难解释。幸运的是，在文档中对此进行了说明。

我在这个问题上已经很晚了，但是我认为这是一个比被接受的答案更明确的答案（这是正确的，但不强调您需要推论的实际重要部分）。

在父POM中，<dependencies>和之间的主要区别<dependencyManagement>是：

本<dependencies>节中指定的工件将始终作为子模块的依赖项包括在内。

<dependencyManagement>如果<dependencies>在子模块本身的部分中也指定了工件，则本节中指定的工件将仅包括在子模块中。你问为什么好？因为您在父级中指定了版本和/或范围，并且可以在子级POM中指定依赖项时将其忽略。这可以帮助您将统一版本用于子模块的依赖性，而无需在每个子模块中指定版本。

该文件在Maven站点是可怕的。dependencyManagement所做的只是将依赖项定义（版本，排除项等）移动到父pom，然后在子pom中，您只需要放置groupId和artifactId。就是这样（除了父pom链之类的东西之外，但这也不是很复杂的-DependencyManagement胜过了父级的依赖关系-但是如果对此或导入有疑问，则Maven文档会更好一些）。

在阅读了Maven网站上的所有“ a”，“ b”，“ c”垃圾并感到困惑之后，我重新编写了他们的示例。因此，如果您有两个项目（proj1和proj2）共享一个公共依赖项（betaShared），则可以将该依赖项移至父pom。在使用它的同时，还可以向上移动任何其他依赖项（alpha和charlie），但前提是对您的项目有意义。因此，对于前面句子中概述的情况，这是在父pom中使用dependencyManagement的解决方案：

<!-- ParentProj pom -->
<project>
  <dependencyManagement>
    <dependencies>
      <dependency> <!-- not much benefit defining alpha here, as we only use in 1 child, so optional -->
        <groupId>alpha</groupId>
        <artifactId>alpha</artifactId>
        <version>1.0</version>
        <exclusions>
          <exclusion>
            <groupId>zebra</groupId>
            <artifactId>zebra</artifactId>
          </exclusion>
        </exclusions>
      </dependency>
      <dependency>
        <groupId>charlie</groupId> <!-- not much benefit defining charlie here, so optional -->
        <artifactId>charlie</artifactId>
        <version>1.0</version>
        <type>war</type>
        <scope>runtime</scope>
      </dependency>
      <dependency> <!-- defining betaShared here makes a lot of sense -->
        <groupId>betaShared</groupId>
        <artifactId>betaShared</artifactId>
        <version>1.0</version>
        <type>bar</type>
        <scope>runtime</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>
</project>

<!-- Child Proj1 pom -->
<project>
  <dependencies>
    <dependency>
      <groupId>alpha</groupId>
      <artifactId>alpha</artifactId>  <!-- jar type IS DEFAULT, so no need to specify in child projects -->
    </dependency>
    <dependency>
      <groupId>betaShared</groupId>
      <artifactId>betaShared</artifactId>
      <type>bar</type> <!-- This is not a jar dependency, so we must specify type. -->
    </dependency>
  </dependencies>
</project>

<!-- Child Proj2 -->
<project>
  <dependencies>
    <dependency>
      <groupId>charlie</groupId>
      <artifactId>charlie</artifactId>
      <type>war</type> <!-- This is not a jar dependency, so we must specify type. -->
    </dependency>
    <dependency>
      <groupId>betaShared</groupId> 
      <artifactId>betaShared</artifactId> 
      <type>bar</type> <!-- This is not a jar dependency, so we must specify type. -->
    </dependency>
  </dependencies>
</project>

就像你说的 dependencyManagement用于将所有依赖项信息提取到公共POM文件中，从而简化了子POM文件中的引用。

当您有多个不想在多个子项目中重新输入的属性时，此功能将非常有用。

最后，dependencyManagement可用于定义工件的标准版本以在多个项目中使用。

在我看来，还有一件事情没有被充分强调，那就是不需要的继承。

这是一个增量示例：

我在parentpom中声明：

<dependencies>
        <dependency>
            <groupId>com.google.guava</groupId>
            <artifactId>guava</artifactId>
            <version>19.0</version>
        </dependency>
</dependencies>

繁荣！我有它在我Child A，Child B和Child C模块：

• 儿童poms继承的违规行为
• 一个地方管理
• 无需在子poms中重新声明任何内容
• 我仍然可以redelcare并覆盖到version 18.0的Child B，如果我想。

但是，如果我最终什么不需要番石榴Child C，也不对未来Child D和Child E模块？

他们仍然会继承它，这是不希望的！ 就像Java God Object代码的味道一样，您可以从类中继承一些有用的位，还可以继承大量不需要的东西。

这就是<dependencyManagement>发挥作用的地方。将其添加到父pom时，所有子模块都停止看到它。因此，您被迫进入确实需要它的每个模块，并再次声明它（Child A并且Child B，尽管没有版本）。

而且，很显然，您没有为此做准备Child C，因此您的模块保持精益。

有一些答案概述了Maven <depedencies>和<dependencyManagement>标签之间的区别。

但是，以下几点简明扼要：

1. <dependencyManagement>允许合并跨不同模块使用的所有依赖项（在子pom级别使用）- 清晰，集中的依赖项版本管理
2. <dependencyManagement>允许根据需要轻松升级/降级依赖关系，在其他情况下，则需要在每个子pom级别上进行锻炼- 一致性
3. <dependencies>标签中提供的依赖项始终会导入，而<dependencyManagement>父pom中提供的依赖项只有在子pom的<dependencies>标签中具有相应条目时才会导入。

抱歉，我晚会很晚。

让我尝试使用mvn dependency:tree命令来解释差异

考虑下面的例子

父POM-我的项目

<modules>
    <module>app</module>
    <module>data</module>
</modules>

<dependencies>
    <dependency>
        <groupId>com.google.guava</groupId>
        <artifactId>guava</artifactId>
        <version>19.0</version>
    </dependency>
</dependencies>

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.apache.commons</groupId>
            <artifactId>commons-lang3</artifactId>
            <version>3.9</version>
        </dependency>
    </dependencies>
</dependencyManagement>

子POM-数据模块

<dependencies>
    <dependency>
        <groupId>org.apache.commons</groupId>
        <artifactId>commons-lang3</artifactId>
    </dependency>
</dependencies>

子POM-应用程序模块（没有额外的依赖性，因此将依赖性保留为空）

 <dependencies>
</dependencies>

在运行mvn dependency:tree命令时，我们得到以下结果

Scanning for projects...
------------------------------------------------------------------------
Reactor Build Order:

MyProject
app
data

------------------------------------------------------------------------
Building MyProject 1.0-SNAPSHOT
------------------------------------------------------------------------

--- maven-dependency-plugin:2.8:tree (default-cli) @ MyProject ---
com.iamvickyav:MyProject:pom:1.0-SNAPSHOT
\- com.google.guava:guava:jar:19.0:compile

------------------------------------------------------------------------
Building app 1.0-SNAPSHOT
------------------------------------------------------------------------

--- maven-dependency-plugin:2.8:tree (default-cli) @ app ---
com.iamvickyav:app:jar:1.0-SNAPSHOT
\- com.google.guava:guava:jar:19.0:compile

------------------------------------------------------------------------
Building data 1.0-SNAPSHOT
------------------------------------------------------------------------

--- maven-dependency-plugin:2.8:tree (default-cli) @ data ---
com.iamvickyav:data:jar:1.0-SNAPSHOT
+- org.apache.commons:commons-lang3:jar:3.9:compile
\- com.google.guava:guava:jar:19.0:compile

Google番石榴在每个模块（包括父模块）中被列为依赖项，而apache commons仅在数据模块（甚至在父模块中）中列为依赖项

如果依赖项是在顶级pom的dependencyManagement元素中定义的，则子项目不必显式列出依赖项的版本。如果子项目确实定义了一个版本，它将覆盖顶级POM的dependencyManagement部分中列出的版本。即，仅在子代未直接声明版本时才使用dependencyManagement版本。

在父POM中，<dependencies>和之间的主要区别 <dependencyManagement>是：

本<dependencies>节中指定的工件将始终作为子模块的依赖项包括在内。

如果在子模块本身的部分中也指定了工件，则本节中指定的工件将仅包括在子模块中。你问为什么好？因为您在父级中指定了版本和/或范围，并且可以在子级POM中指定依赖项时将其忽略。这可以帮助您将统一版本用于子模块的依赖性，而无需在每个子模块中指定版本。

用我自己的话说，您parent-project可以帮助您提供两种依赖：

• 隐式依赖项：<dependencies>您的部分中定义的所有依赖项parent-project都被所有child-projects
• 显式依赖项：允许您选择要在中应用的依赖项child-projects。因此，您可以使用该<dependencyManagement>部分声明要在different中使用的所有依赖项child-projects。最重要的是，在本节中，您定义了一个，<version>因此您不必在中再次声明它child-project。

将<dependencyManagement>在我的观点（纠正我，如果我错了）只是帮助你集中你的依赖关系的版本是有用的。这就像一种辅助功能。

在Eclipse中，中的另一个功能dependencyManagement。如果dependencies不使用它，则在pom文件中会发现未找到的依赖项。如果dependencyManagement使用，则未解决的依赖项在pom文件中不会被注意到，并且错误仅在java文件中出现。（进口等）

最好将两者之间的区别引入Maven网站文档中提供的dependencyManagement元素的必要定义和充分定义：

依赖管理

“继承自此项目的项目的默认依赖关系信息。本节中的依赖关系不会立即得到解决。相反，当从此项目派生的POM声明由匹配的groupId和artifactId描述的依赖项时，版本和本节中的其他值如果尚未指定，则用于该依赖项。” [ https://maven.apache.org/ref/3.6.1/maven-model/maven.html ]

应该将其与其他页面上的更多信息一起阅读：

“ ..用于将依赖项引用与dependencyManagement部分进行匹配的最小信息集实际上是{groupId，artifactId，type，classifier}。在许多情况下，这些依赖项将引用没有分类器的jar工件。由于类型字段的默认值为jar，默认分类器为null，因此这使我们可以简化设置为{groupId，artifactId}的标识。” [ https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html ]

因此，依赖项的所有子元素（作用域，排除项等）（除了groupId，artifactId，类型，分类器，而不仅是版本）都可以在该点进行锁定/默认设置（并由此继承）在此之后），您可以在dependencyElement中指定依赖项。如果您将类型和分类器子元素指定为依赖项（请参阅第一个引用的网页以检查所有子元素）分别为jar和not null，则需要{groupId，artifactId，classifier，type}引用（解析）该依赖关系，该依赖关系在依赖项中的任何时候都源自dependencyManagement元素。否则，如果您不打算覆盖分类器和类型的默认值（分别为jar和null），则{groupId，artifactId}就足够了。因此，default是该定义中的一个好关键字。任何子元素（groupId除外，

因此，无论是作为dependencyManagement元素的引用还是作为独立的依赖项，在dependencyManagement之外的任何依赖项元素都将立即得到解决（即，安装到本地存储库中并且可用于类路径）。