a"；“多插件”；Java web应用程序-管理公共库和冲突版本

我是一个网络项目的新手，在这个项目中我们必须开发插件（在那个特定的项目中称为“扩展”）。主应用程序在修改过的TomcatWeb服务器中运行，我们必须在公共lib文件夹中添加插件“.jar”。我仍然不太习惯这个应用程序以及它是如何工作的，但是我非常确定这个应用程序及其所有插件都有一个通用的类加载器。该库文件夹中的所有库都是共享的

我的问题是如何在这种环境下处理插件的依赖关系和可能冲突的版本。

我们是否应该共享库，例如

some-common-lib-1.3.4

作为lib文件夹中的jar，插件需要使用库时必须使用这些版本

或者插件是否应该包含自己的依赖项（例如使用），以便同一依赖项的不同版本不是问题

我看到的一个问题是，所有插件都要使用具有特定版本的共享库，这与可传递依赖性有关。如果一个公共库依赖于

some-transitive-dependency-1.0.0

，而我们有一个特定的插件，它需要一个新库，而这个库本身对

some-transitive-dependency-2.0.0

具有传递依赖性，那么我们就完蛋了。。。然后，我们需要lib文件夹中的

some-transitive-dependency-1.0.0

和

some-transitive-dependency-2.0.0

，谁知道会发生什么

此外，如果对于一个特定的插件，我们需要将依赖项更新为新的主要版本，那么我们可能必须更新所有插件，因为该库是所有插件共享的

---

在这种情况下有过真实的经历吗？有什么建议吗？

既然OSGI不是一个选项，而且可能每个人都可以创建新的插件，唯一可行的方法就是使用shade插件或类似的技术来分离它们

因为你不能分离类加载器，而重新编译所有插件（你可能连源代码都没有）真的不是一个选项，有时你甚至可能会有无法解决的冲突（ASM1.x和2.x完全不兼容），所以你必须使用你自己的“穷人的OSGI”和shade

---

但是，请注意，这确实减少了插件协同工作或共享主应用程序中未定义的公共数据的选项。

看起来您应该研究在Tomcat上部署OSGI容器（如Karaf），并让它处理依赖性破坏…@Cascader，而不使用OSGI或Jigsaw，人们通常如何处理这种情况？这就是我所好奇的！因为我很确定我们不能改变这个应用程序的工作方式和加载它的库：它们都必须放在lib文件夹中。