Java 在具有大量依赖项的项目中进行依赖项管理的最佳实践

我们的项目就像是大量其他库的适配器/门面接口。这些依赖项在某种程度上是重叠的，有时是冲突的，有时甚至是因为错误版本的依赖项提供了相同接口的错误行为而导致项目中断。 我们正在使用Ivy和Ant进行基本的依赖关系管理。

---

早期管理依赖关系和检测错误行为的最佳实践是什么？

这个问题的重要部分是关于过程，而不是工具

如果项目的依赖项属于其他团队或第三方，则该项目必须明确接受每个新依赖项的每个新版本。允许依赖项自行升级将允许它们在没有警告的情况下中断依赖项项目，这听起来就像是正在发生的事情

每个依赖项都必须发布已知版本，无论是版本控制中的二进制文件或标记，还是适合堆栈的任何内容。每当项目想要升级依赖项时，它都必须测试升级的结果。（像往常一样，全面的自动化测试将是一个很大的帮助。）如果失败（或者是因为依赖关系刚刚被破坏，或者是因为依赖关系带来了不兼容的可传递依赖关系版本），放弃升级，向依赖关系的所有者报告问题，然后在他们发布解决问题的版本后重试。如果成功，请更改项目在其生成配置中使用的依赖项的版本

理想情况下，项目将一次升级一个依赖项，并分别对每个升级进行全面测试。如果有必要同时升级多个依赖项（可能是因为两个依赖项都依赖于第三个依赖项，而系统中只能有一个版本），这很好，尽管这是一个更大的更改，因此风险更大。如果您的项目具有这样的可传递依赖项，那么在尽可能多的合理版本上使它们向后兼容是值得的

---

当然，很多工具都很容易支持这个过程：只需将每个依赖项绑定到特定的版本。

其他库是由您编写的还是第三方编写的？当您有冲突的版本，并且版本控制是由可转换的依赖项管理系统提供的时，您会陷入两难境地，可能需要做一些类似依赖树的事情（我不知道如何使用Ivy）并开始手动计算冲突。即使使用Maven，您也需要手动操作，尽管它可以告诉您为什么库由于冲突而被忽略，例如@DaveSchweisguth它们主要是我们自己的库，但由不同的团队管理，甚至跨团队管理。如果您的内部库为接口提供了“错误行为”，或者无声地失败，没有依赖关系管理系统能够对此做很多工作。@Dmitri这是由于提供了错误的版本。我在寻找一些指导方针。我知道没有一个系统可以单独完成这个任务(