大型项目的依赖项管理

Question

我正在做一个相当大的项目。我们有很多项目，每个项目都有依赖关系。我们使用maven，通常我们不会有任何问题。因此，在不提供更多细节的情况下，假设对于给定的项目，假设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有大量的项目依赖于，比方说，object-pooling，它也依赖于许多其他更多的组件，如(utils和multithreading)。

对于object-pooling开发人员来说，生活是美好的。这是一个非常稳定的模块，一切都进行得很顺利。与任何其他模块一样，它也有依赖项。object-pooling开发人员都是先生和美丽的女士，当他们发现一个关键的bug时，他们会更新所有依赖于object-pooling的项目。

现在，object-pooling的1.9.3.1版本是稳定的，并且没有已知的关键错误。开发人员非常努力地添加了大量新功能，一段时间后，他们发布了2.0.0.0版本。当然，在1.9.3.1和2.0.0.0之间，还有一些中间版本(例如1.9.3.1、1.9.3.2、1.9.4.0、1.9.5.3等)。正如我所说的，object-pooling开发人员的生活是美好的。Version 2.0.0.0有新的特性和大量的修复。

然而，对于tps-reports开发人员来说，地狱就在眼前。他们使用1.9.3.1已经有很长一段时间了，因为这个版本没有已知的bug，所以他们对旧版本很满意。现在，他们想要使用修改后的object-pooling，所以他们更新了他们的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上，或者任何奇怪的组合上。

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

谢谢!

Answer 1

对不起，这里没有什么灵丹妙药：的答案是单元测试。项目越大，自动测试就变得越重要。

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

现在，您可以将测试用例发送给对象池开发人员，并告诉他们，在他们通过此测试和其他测试之前，您不会升级。这将使他们的生活有点像你的生活，并提供足够的测试用例，你的生活最终会更像他们的生活:-)

如果bug在他们的依赖库中，他们将不得不对他们的下游开发人员做同样的事情。

Answer 2

我会使用几个pom配置，并将它们都放到continouos集成服务器中，以获得某些测试在哪些情况下失败的概述。