Question

我的问题与在一系列相关项目中管理第三方依赖关系的最有效方法有关。目标是维护组织“标准”，以便使用主要的第三方（例如，Hibernate，Spring，Apache Commons等）依赖项，而不会产生不必要的构建开销。我会在一些背景下问这个问题。

我们拥有越来越稳定的产品，其构建由Maven管理。目前，它包括3个多模块Web应用程序和一些独立的“可执行”项目以及大约20个共享依赖项。我们喜欢Maven并且无法想象在没有它的情况下我们目前能够做的一些事情 - 特别是对于共享的依赖关系。

共享依赖关系网络是多层的，并且具有（例如）

的情况

Project A    <-----
   ^              |
   |           Project B
   |              ^
   |              |
   |           Project C
   |              ^
   |              |
Project D --------

没有什么太疯狂或周期性的。

但是......在构建时确实会产生一些疲劳的级联 - 特别是因为项目与一个多模块的主项目没有足够的密切关系。

我开始接受这种级联构建作为生活中的事实。也就是说，当A更改时，请将其新版本发送到B和D，但请注意不要在D等之后构建C < / p>

但是，如果A，B和D都有直接的第三方依赖项（通常是Apache Commons项目或Spring模块），我厌倦了在每个项目中编写版本号 - 并且有点担心它们在两个项目之间失去同步。

因此，在我最新的依赖更新迭代中，我创建了一个“框架”项目。它只有一个大的<dependencyManagement>节点，它“强制”了已知的常见第三方依赖项的版本号。

根据Maven recommendations，我在庞大的帝国中制作了每个项目都包含这个节点：

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>com.group</groupId>
      <artifactId>framework</artifactId>
      <version>${version.framework}</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

起初看起来很聪明。然后，现实开始了。

过去，如果Project C的第三方依赖关系发生了变化，我只需要更新C（然后更新任何直接依赖它的项目 - D在上面的例子中。）

现在，我必须发布框架，在所有项目中更新框架版本并释放所有内容，即使对某些项目没有直接影响。如果我知道是这种情况，我可以（有时会）跳过项目......但是在某些项目中，框架版本号会以0.0.x的速度下降。

新系统具有价值 - 如果多个第三方依赖项同时发生变化且大多数项目受到影响，我可以有效地推动大量变更。

但是，最终，似乎我已经交换了一个问题（在多个项目中重复相同的Apache Commons项目的相同版本号）与另一个问题（不必要的项目更新）。旧方法适用于微更新;新方法适用于宏/多更新。

我是否遗漏了“Enterprise Maven 101”中的某些内容，这会让整个设置变得更容易管理？

更重要的是：在这种相互依赖（但不是多模块）项目的网络中管理第三方依赖项版本号的最有效方法是什么？

管理企业中的跨项目依赖关系

0 个答案: