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开发人员都是绅士和公平的女士，每当他们发现关键错误时，他们都会更新所有依赖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>

他们发现他们有新的错误。毋庸置疑，当这些错误取决于1.9.3.1的版本object-pooling时，这些错误就不存在了。他们深入研究了他们的代码库日志，他们发现，不仅object-pooling人已经完成了数千次提交，而且他们还使用了最新版本的multithreading和utils，也有很多提交。

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

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

谢谢！

Answer 1

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

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

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

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

Answer 2

我会使用几个pom配置并将它们全部放入一个持续集成服务器中，以便了解某些测试失败的情况。

大项目的依赖管理

2 个答案: