dependencyManagement和范围

Question

我通常把一<dependencyManagement>节放进去parent-project/pom.xml.本<dependencyManagement>节包含我的子模块的所有依赖项的声明和版本(例如没有<scope>元素):

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

在所有子模块(即moduleX/pom.xml)中,我有:

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

显然,在这个例子中,我重复<scope>test</scope>多次相同的依赖(在每个子模块中需要junit一次).

我的问题是:
有关<scope>申报的最佳做法是什么？
把它放进去更好<dependencyManagement>吗？
或者将它放在<dependencies>子模块的部分(如本文中)更好？为什么？
这个问题有没有明确的答案？

Answer 1

派对有点晚了,但我会加两分钱.我最近遇到了一个非常难以调试的问题.我有一个父pom来管理多个项目的依赖关系.我设置了它们之间共有的所有依赖项,包括groupId,artifactId,version和最常见的范围.我的想法是,如果它与最常见的范围一致,我就不必在每个项目的实际依赖部分中包含范围.当某些依赖项显示为传递依赖项时,会出现问题.例如,如果

• A在编译范围内取决于B.
• B在编译范围内依赖于C.
• C设置为在parent的dependencyManagement中提供

然后确定提供A对C的传递依赖性.我不确定这是否有意义,但它确实令人困惑.

无论如何,为自己省去麻烦,并将范围从您的依赖管理中移除.

Answer 2

dependencyManagement就是在这里定义所有项目子模块的依赖关系版本,本节中唯一相关的范围是importBOM.

范围必须在dependencies章节中定义.

(对于给定的依赖项,它确定使用上下文.它允许仅在需要执行时包含依赖项.例如,ear将不与Java-ee依赖项(范围provided)打包, 因为它将在目标服务器上找到它们.)

[编辑]

第一条语句有一个例外,范围provided在dependencyManagement节将在覆盖范围定义dependencies部分.请参阅DependencyManagement以强制范围

Answer 3

与其他答案一样，最佳实践是从 dependencyManagement 中排除范围，并在定义依赖项时显式指定它。在极少数情况下，您希望在不同范围内使用相同依赖项的不同版本，例如，编译应用程序时使用一个版本，而在运行应用程序时使用不同版本 - 我能想到的唯一情况是您想要显式运行您的应用程序针对不同版本的库进行测试，以防用户使用该版本而不是您指定的版本。

如果您在 dependencyManagement 中定义范围，它会将该版本的使用限制为仅定义的范围 - 因此任何其他范围都将选取依赖项的随机版本。昨天我遇到了这个问题，当时我们在 dependencyManagement 中定义了带有测试范围的 junit 4.12，但我们的通用测试框架模块使用带有编译范围的 junit，所以它选择了版本 4.8.2。