大公司如何解决包依赖冲突问题？

Question

如图，一个app（Java）引用了两个第三方包jar（packageA和packageB），分别引用了packageC-0.1和packageC-0.2。如果 packageC-0.2 与 packageC-0.1 兼容，它会工作得很好。然而，有时 packageA 使用了 packageC-0.2 不支持的东西，而 Maven 只能使用最新版本的 jar。这个问题也被称为“Jar Hell”。

在实践中很难重写包 A 或强制其开发人员将包 C 更新到 0.2。

你如何解决这些问题？这种情况经常发生在大型公司中。

我必须声明这个问题主要发生在大公司，因为大公司有很多部门，每次某些开发人员使用新版本的新功能时让整个公司更新一个依赖项会非常昂贵一些依赖 jars。这对小公司来说没什么大不了的。

任何回应将不胜感激。

让我先扔一块砖，然后再得到一颗宝石。

阿里巴巴是世界上最大的电子商务公司之一。我们通过创建一个名为 Pandora 的隔离容器来解决这些问题。它的原理很简单：将这些中间件打包在一起，并使用不同的类加载器加载它们，这样即使它们引用了不同版本的相同包，它们也可以很好地协同工作。但这需要 Pandora 提供的运行时环境作为 tomcat 进程运行。不得不承认，这是一个沉重的计划。Pandora 是基于 JVM 通过类加载器加上类名来识别一个类这一事实而开发的。

如果您知道有人可能知道答案，请与他/她分享链接。

Answer 1

我们是一家大公司，我们经常遇到这个问题。我们拥有跨越多个开发人员组的大型依赖树。我们所做的：我们通过由 jar 的维护者发布的“推荐版本”的 BOM（Maven 依赖管理列表）来管理版本。这样，我们确保使用最新版本的工件。我们尝试通过将开发人员组内部使用的功能与他们提供给其他组的功能分开来减少大型依赖树。但我承认我们仍在努力寻找更好的策略。我还要提一下，使用“微服务”是解决这个问题的一种策略，但在许多情况下，这对我们来说不是一个有效的策略（主要是因为我们不能再在数据库上进行全局事务）。

Answer 2

在Maven多模块项目中，POM在做统一版本管理的时候，依赖管理节点一般都定义在父文件中。节点类声明的依赖节点的内容是关于统一定义的资源版本。直接定义的依赖节点中的资源不需要引入版本阶段。海关的内容如下：在父 pom 中<dependencyManagement>&nbsp;&nbsp; &nbsp; <dependencies >&nbsp;&nbsp; &nbsp; &nbsp; <dependency >&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; <groupId>com.devzuz.mvnbook.proficio</groupId>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; <artifactId>proficio-model</artifactId>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; <version>${project.version}</version>&nbsp;&nbsp; &nbsp; &nbsp; </dependency >&nbsp;&nbsp; &nbsp; </dependencies >&nbsp;&nbsp; </dependencyManagement>在你的模块中，你不需要设置版本<dependencies >&nbsp;&nbsp; &nbsp; <dependency >&nbsp;&nbsp; &nbsp; &nbsp; <groupId>com.devzuz.mvnbook.proficio</groupId>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp;<artifactId>proficio-model</artifactId>&nbsp;&nbsp; &nbsp; </dependency >&nbsp;&nbsp; </dependencies >&nbsp;这将避免不一致的问题。

Answer 3

这是java世界中的普遍问题。您最好的选择是定期维护和更新packageA 和 packageB 的依赖项。如果您可以控制这些应用程序 - 花时间去做。如果您没有控制权，请要求供应商或作者进行定期更新。如果 packageA 和 packageB 都在内部使用，您可以使用以下做法：让您公司的所有内部项目都引用parentMavenpom.xml中定义常用第三方库的“最新”版本的 a。例如：&nbsp;&nbsp;&nbsp;&nbsp;<framework.jersey>2.27</framework.jersey> &nbsp;&nbsp;&nbsp;&nbsp;<framework.spring>4.3.18.RELEASE</framework.spring> &nbsp;&nbsp;&nbsp;&nbsp;<framework.spring.security>4.2.7.RELEASE</framework.spring.security>因此，如果您的项目“A”使用 spring，如果它们使用您公司的“父”pom 的最新版本，则它们都应该使用 4.3.18.RELEASE。当新版本的 spring 发布并且需要时，您更新公司的父 pom，并强制所有其他项目使用该最新版本。这将解决许多依赖项不匹配问题。别担心，这在java世界中很常见，你并不孤单。只需谷歌“罐子地狱”，你就可以在更广泛的背景下理解这个问题。顺便说一下mvn dependency:tree，您的朋友可以隔离这些依赖问题。