大公司如何应对包依赖冲突问题？

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或迫使其开发人员将packageC更新为0.2.

你如何解决这些问题？这通常发生在大型公司中.

我必须声明这个问题主要发生在BIG公司,因为大公司有很多部门,每当某些开发人员使用新版本的新功能时,让整个公司更新一个依赖关系会非常昂贵.一些依赖罐.这对小公司来说并不是什么大不了的事.

任何回复都将受到高度赞赏.

让我扔掉一块砖,以便先获得宝石.

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

如果您知道某人可能知道答案,请与他/她分享链接.

Answer 1

这个问题一般无法回答。过去我们通常只是不使用不同版本的依赖关系。如果版本发生更改，则需要团队/公司范围内的重构。我怀疑大多数构建工具都可以实现这一点。

但要回答你的问题..简单的答案：不要在一个编译单元（通常是一个模块）内使用一个依赖项的两个版本

但如果您确实必须这样做，您可以编写一个引用该库的旧版本的包装器模块。

但我个人的观点是，在一个模块内不需要这些构造，因为“一个模块”应该相对较小以便于管理。否则，这可能是一个强有力的指标，表明该项目可以使用一些模块化重构。然而，我很清楚，“大型公司”的一些项目可能会变得一团糟，没有“好的”选择。我猜你正在谈论这样一种情况，其中 packageA 与 packageB 属于不同的团队……由于缺乏分离和固有的依赖问题，这通常是一个非常糟糕的设计决策。