大项目的依赖管理

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的拥有吨的依赖，比如项目，object-pooling，这也取决于许多其他更多组件，例如（utils和multithreading）。

生活对object-pooling开发人员有好处。这是一个非常稳定的模块，并且一切顺利。与其他任何模块一样，它也具有依赖性。 object-pooling开发人员都是绅士和公平的女士，每当他们发现一个重要的bug时，他们更新所有依赖于object-pooling的项目。

现在，版本1.9.3.1的object-pooling是稳定的并且没有已知的关键错误。开发人员非常努力地添加大量新功能，并在一段时间后发布版本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开发者来说很好。版本2.0.0.0具有新功能和大量修复程序。

然而，到底是指日可待为tps-reports开发。他们已经使用1.9.3.1已经有一段时间了，因为这个版本中没有已知的错误，所以他们对旧版本很满意。现在，他们要使用的修补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。毋庸置疑，当这些错误依赖于的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失败。

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

如果错误是在他们的依赖库，他们将不得不做同样的事情，以自己的下游开发人员。

Answer 2

我会使用几个pom配置，并将它们全部放入连续性集成服务器中以获得某种测试失败情况下的概述。