如果子模块是独立版本控制的，如何安排 maven reactor 的依赖管理？答案

【问题标题】：How to arrange dependency management for maven reactor if child modules are versioned independently?如果子模块是独立版本控制的，如何安排 maven reactor 的依赖管理？
【发布时间】：2015-07-27 00:03:06
【问题描述】：

我们有一个反应堆 pom，它的子模块是独立版本的，即。子模块声明它自己的版本，独立于主 pom 的版本。然而，两个子模块之间存在依赖关系。应该如何将此依赖配置为始终使用 reactor pom 的实际模块声明的版本？

我希望我可以在根 pom 中设置依赖管理并使用一些隐式属性来确定子模块的版本，但我能找到最好的选择：

${session.projectDependencyGraph.sortedProjects[0].version}

或者干脆

${reactorProjects[0].version}

所以根 pom 中的依赖管理看起来像这样：

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>mygroup</groupId>
      <artifactId>mySubmodule</artifactid>
      <version>${reactorProjects[0].version}</version>
    </dependency>
  </dependencies>
</dependencyManagement>

看起来不可靠，因为添加新模块或依赖项时反应器顺序可能会发生变化。

也许这种使用场景在设计上是不鼓励的，然后我想知道为什么。

编辑：正如 cmets 中所建议的，在父 POM 中声明具有子版本的全局属性可能是新版本 Maven 的一个选项。然而，我希望看到一些关于更广泛后果的分析，如工作流、发布、目录和存储库设置、一些插件使用（例如版本插件）等。例如，我认为这种方法的直接后果是我必须发布每当发布任何子模块时，父模块。虽然这是可行的，但它会影响拥有独立版本控制的最初想法。

【问题讨论】：

您是否尝试将模块的版本声明为根 pom 中定义的属性？
我能做到，问题是它是否是正确的方法。我不确定当前的最佳实践，但我认为在 maven 坐标声明中使用属性以前是一种不好的做法，甚至是不可能的。如果您正在谈论使用子版本的手动副本声明属性，那么这就是我要避免的。
This answer 声称它在 Maven 2.x 中是不允许的。对于此处的 Maven 3.2.1，project/parent/version 仍然如此，但它适用于 project/version。如果它有效并且符合我的需要，我会使用它。

标签： maven maven-reactor

【解决方案1】：

我建议在父 pom 中使用 dependencyManagement。您可以在那里定义所有依赖项的所有 de 版本。然后可以省略不同模块中的依赖版本

所以在父级中：

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>mygroup</groupId>
      <artifactId>myModule</artifactid>
      <version>1.2.3</version>
    </dependency>
  </dependencies>
</dependencyManagement>

在你使用的模块中

  <dependencies>
    <dependency>
      <groupId>mygroup</groupId>
      <artifactId>myModule</artifactid>
    </dependency>
  </dependencies>

将使用dependencyManagement 中定义的版本。

我建议在父 pom 中定义所有依赖项的版本。

【讨论】：

这实际上正是我想做的事情，我只是想避免在dependencyManagement 部分本身的重复版本定义。我已经更新了我的问题，以便更清楚。

【解决方案2】：

我在Maven mailing list 上开始了一个关于这个主题的帖子，我在这里发布 TL；DR 答案：

我预期的具有隐式属性的解决方案通常是不可能的，因为它不仅会在构建期间被评估，而且在将构建的工件用作其他项目中的依赖项时也会被评估，并且它的评估可能会产生不可预测的结果，因为隐式属性的上下文完全不同。（我很愚蠢，前段时间我在 ${project.version} 属性上遇到了同样的问题）

一般而言，从一位开发人员的角度来看，该问题仅考虑一个项目中的一种场景。在邮件列表线程中，还有其他观点导致在依赖管理或显式属性中对依赖版本号进行硬编码，即使有其他可能。

【讨论】：