大型项目的依赖管理

Question

我正在一项相当大的项目中工作。我们有许多项目，每个项目都有依赖关系。我们使用Maven，通常不会遇到任何问题。因此，不详细介绍，假设对于给定的项目例如tps-reports，pom.xml的依赖关系部分如下：

  <name>TPS-Reports</name>
  <description>
   TPS Reports frontend.
  </description>
  <dependencies>
   <dependency>
    <groupId>com.initech</groupId>
    <artifactId>gui-components</artifactId>
    <version>2.5</version>
   </dependency>
   <dependency>
    <groupId>com.initech</groupId>
    <artifactId>multithreading</artifactId>
    <version>3.7</version>
   </dependency>
   <dependency>
    <groupId>com.initech</groupId>
    <artifactId>utils</artifactId>
    <version>2.3.0.0</version>
   </dependency>
   <dependency>
    <!-- TODO: update to new version -->
    <groupId>com.initech</groupId>
    <artifactId>object-pooling</artifactId>
    <version>1.9.3.1</version>
   </dependency>
  </dependencies>

现在，Initech有很多项目都依赖于例如对象池的技术，这也依赖于许多其他组件，如(工具和多线程)。 对象池开发人员的日子很好过。它是一个相当稳定的模块，一切都顺利。像任何其他模块一样，它也有依赖项。 对象池的开发人员都是绅士和女士，每当他们发现关键错误时，他们都会更新所有依赖于对象池的项目。

现在，版本 1.9.3.1 的 对象池 是稳定的，并且没有已知的关键错误。开发人员非常努力地添加了大量新功能，经过一段时间后，他们发布了 2.0.0.0 版本。当然，在 1.9.3.1 和 2.0.0.0 之间，还有中间版本（例如 1.9.3.2 ， 1.9.4.0 ， 1.9.5.3 等）。正如我所说，对象池开发人员的日子很好过。版本 2.0.0.0 具有新功能和大量修复。

但是，对于 tps报告开发人员来说，地狱就在眼前。他们已经相当长时间使用 1.9.3.1 ，由于这个版本中没有已知的错误，他们对旧版本感到满意。现在，他们想使用重新设计的对象池，因此更新他们的 pom.xml 以使用版本 2.0.0.0 ，它现在看起来像这样：

  <name>TPS-Reports</name>
  <description>
   TPS Reports frontend.
  </description>
  <dependencies>
   <dependency>
    <groupId>com.initech</groupId>
    <artifactId>gui-components</artifactId>
    <version>2.5</version>
   </dependency>
   <dependency>
    <groupId>com.initech</groupId>
    <artifactId>multithreading</artifactId>
    <version>3.7</version>
   </dependency>
   <dependency>
    <groupId>com.initech</groupId>
    <artifactId>utils</artifactId>
    <version>2.3.0.0</version>
   </dependency>
   <dependency>
    <!-- use object poooling's new features -->
    <groupId>com.initech</groupId>
    <artifactId>object-pooling</artifactId>
    <version>2.0.0.0</version>
   </dependency>
  </dependencies>

他们发现有新的 bug。不用说，这些 bug 在他们依赖 object-pooling 的版本 1.9.3.1 时并不存在。他们查看代码仓库的日志，发现除了 object-pooling 团队已经做了数千次提交，他们还使用了最新版本的 multithreading 和 utils，这两个项目也都有很多次提交。

显然，问题可能存在于无数地方。它可能在 object-pooling 上，它可能是在 object-pooling 和 tps-reports 之间的交互中，也可能在 multithreading 或 utils 上，或者是任何奇怪的组合中。

问题是：你们如何解决这种问题？你们如何管理依赖于其他项目的大型项目？是否有一些工具可以帮助完成这项任务？

谢谢！

- chahuistle

Answer 1

很抱歉，这里没有万能的解决方法: 单元测试是答案。项目越大，自动化测试就越重要。

在您的情况下，即使错误出现在手动测试中，最终也会归结为使用库的特定情况，您可以将其减少到单元测试。测试将在1.9.3.1中通过，在2.0.0.0中失败。

现在，您可以将测试用例发送给对象池开发人员，并告诉他们在他们使此及其他测试通过之前，您不会升级。这将使他们的生活与您的生活有些相似，并且如果有足够的测试用例，您的生活最终也将更像他们的生活 :-)

如果错误出现在他们的依赖库中，则他们必须向下游开发人员执行相同的操作。

- Sasha O

Answer 2

我会使用多个pom配置，并将它们全部放入一个持续集成服务器中，以便在哪些情况下某些测试失败的情况下获得概述。

- MS.

---

嗯...但这意味着你必须测试所有依赖的所有可能版本...另外，如果在人工测试而不是单元测试期间出现错误怎么办？ - chahuistle