java - war-package 内的依赖关系与共享库内的依赖关系

Question

通常，依赖项捆绑在 Java .war 包内。

但是，也可以将依赖项放入共享库中，以便为每个已部署的 Artifact 使用相同的依赖项。

问题:每种方法的优点和缺点是什么？您会在什么情况下使用它们？

最大的要求是直观性/可维护性。我不太关心内存消耗、磁盘空间使用、带宽等，因为这些都很便宜。

无论如何，每个点都有一些要点:

在 WAR 中包含依赖项:

• “事实上”的方法(？)
• 易于维护(需要较少的配置和脚本等)
• 易于部署到应用服务器
• 每个模块都可以在库上定义特定版本
• 降低类加载错误的风险？

使用共享库:

• 减少内存消耗(微不足道？)
• WAR 部署可以访问相同的实例/变量等，因为它们共享类路径？听起来真的很糟糕吗？ (它真的是这样工作的吗？还是它们在不同的上下文中运行，只是使用相同的物理文件？)
• 使分发和部署变得更加困难，因为必须单独维护/部署依赖项
• 包尺寸较小(琐碎)
• 无需实际重新部署 WAR 应用即可升级依赖项(这有什么好处，真的......)

当然，我们可以利用这两种方法的最佳方面，只提供公共(public)库作为共享库，并在 WAR 中包含版本特性。然而，这会增加一倍的维护工作量，而且感觉像是一个禁忌。

目前我正在使用 Glassfish 3.1.1，但这个问题实际上与应用程序服务器无关。

Answer 1

这取决于您的操作。如果您在服务器上部署应用程序，并且此类服务器的数量非常有限(例如集成、QA、生产)，并且您有大量依赖项，您可以将依赖项放入共享库。

如果您要将 war 发送给必须在其服务器上部署此 war 的第三方用户，这是非常烦人的。可怜的用户必须在他的共享库中安装所有必需的依赖项(以及依赖项的依赖项)。

如果您必须在不属于您的服务器上安装您的应用程序，或者必须在运行多个企业应用程序的服务器上安装您的应用程序，您就不能使用此方法。您必须将所有依赖项打包到您的 war 文件中。否则冲突是不可避免的。