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 ?为什么不在需要的模块中直接定义它呢?


当前回答

在Eclipse中,dependencyManagement中还有一个特性。当使用依赖项而不使用它时,将在pom文件中注意到未找到的依赖项。如果使用dependencyManagement,则pom文件中不会发现未解决的依赖项,错误只出现在java文件中。(进口等…)

其他回答

<dependencyManagement>的一个用例是解决库版本冲突。

例子:

项目A有库x:1.0.1 项目A有B库 B库有库x:1.0.0

有了这个设置,你会得到项目A同时x:1.0.1和x:1.0.0的冲突。 要解决这个问题,您可以将特定版本的依赖项放入<dependencyManagement>标签中

我不建议使用dependencyManagement。

使用它的唯一好处是您可以在父pom中定义版本,而不需要在子pom中再次定义它。但是如果你有一组项目(特别是微服务项目)。使用dependencyManagement没有任何好处。

不同的项目可能需要不同的依赖关系。为什么要从同一个父pom继承它。尽可能保持简单。如果一个项目需要A依赖项,则将其添加到pom文件中。不要让开发人员感到困惑。

两者之间的区别最好体现在Maven网站文档中提供的dependencyManagement元素的必要且充分的定义中:

dependencyManagement

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

你可以在另一页阅读更多信息:

“. .匹配依赖引用到依赖管理节的最小信息集实际上是{groupId, artifactId, type, classifier}。在许多情况下,这些依赖关系将引用不带分类器的jar工件。这允许我们将标识集简写为{groupId, artifactId},因为类型字段的默认值是jar,默认分类器是null。[https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html]

Thus, all the sub-elements (scope, exclusions etc.,) of a dependency element--other than groupId, artifactId, type, classifier, not just version--are available for lockdown/default at the point (and thus inherited from there onward) you specify the dependency within a dependencyElement. If you’d specified a dependency with the type and classifier sub-elements (see the first-cited webpage to check all sub-elements) as not jar and not null respectively, you’d need {groupId, artifactId, classifier, type} to reference (resolve) that dependency at any point in an inheritance originating from the dependencyManagement element. Else, {groupId, artifactId} would suffice if you do not intend to override the defaults for classifier and type (jar and null respectively). So default is a good keyword in that definition; any sub-element(s) (other than groupId, artifactId, classifier and type, of course) explicitly assigned value(s) at the point you reference a dependency override the defaults in the dependencyManagement element.

因此,在dependencyManagement之外的任何依赖元素,无论是作为某个dependencyManagement元素的引用,还是作为独立的依赖元素,都将立即被解析(即安装到本地存储库并可用于类路径)。

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

下面是一个增量的例子:

我在父母的遗言中声明:

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

繁荣!我把它放在我的子A、子B和子C模块中:

由子poms继承的隐式 一个单独的地方来管理 不需要在child pooms中重新声明任何内容 如果我想,我仍然可以在子B中重新调用和覆盖到18.0版本。

但是,如果我最终在Child C中不需要番石榴,在未来的Child D和Child E模块中也不需要番石榴呢?

他们仍然会继承它,这是不希望的! 这就像Java的God Object代码一样,从类中继承了一些有用的部分,同时也继承了大量不需要的东西。

这就是<dependencyManagement>发挥作用的地方。当你把它添加到你的父pom,你所有的子模块停止看到它。因此,你被迫进入每个单独的模块,确实需要它,并再次声明它(子A和子B,但没有版本)。

显然,您不会为Child C这样做,因此您的模块仍然是精简的。

如果你无论如何都有一个parent-pom,那么在我看来,使用<dependencyManagement>只是为了控制版本(可能还有范围)是一种浪费空间的行为,而且会让初级开发人员感到困惑。

无论如何,在某种父-pom文件中,您可能会有版本的属性。为什么不直接在子pom中使用这个属性呢?这样,您仍然可以为所有子项目一次更新属性中的版本(在父-pom内)。这与<dependencyManagement>具有相同的效果,只是没有<dependencyManagement>。

在我看来,<dependencyManagement>应该用于“真正的”依赖项管理,比如排除等。