辩论：将第三方库添加到战争中是个好主意吗？答案

【问题标题】：debate: Is adding third party libraries to a war a good idea?辩论：将第三方库添加到战争中是个好主意吗？
【发布时间】：2010-06-17 17:14:58
【问题描述】：

我们正在进行一场辩论。

一个。组装 Web 应用程序的“标准”方式。使用我们所有的应用程序工件创建一个 WAR，所有其他组件（如 hibernate 和 memcached 等）都部署在 tomcat/shared/lib 区域中。

b.用包含的所有内容创建一场巨大的战争，而 tomcat/shared/lib 中没有任何内容。

优点 - 它使事物保持模块化并且战争很小。缺点 - 对 shared/lib 的依赖必须由部署过程来管理。

b 的优点 - 所有依赖项都由构建过程控制，消除了任何错误空间。 b 的缺点 - 战争真的非常非常大。如果您通过网络部署到大型场，则可能会产生影响。

想看看其他人对此有何想法。

【问题讨论】：

【解决方案1】：

实际上，我认为 B 是“标准”方式 :-)

我几乎总是选择 B。这对我们的客户来说更简单——他们中的许多人不具备管理 Java 应用程序服务器的技能——他们只需将 WAR 放到我告诉他们的地方，一切正常。

它也适用于我们的构建和部署 - WAR 是使用 maven 构建的，因此包含所有必要的依赖项，也可以使用 cargo 插件部署到我们的 QA 应用服务器。

当您有多个需要休眠或其他依赖但版本不同的 web 应用程序时，它还可以避免“战争地狱”。

只有当我完全控制应用程序服务器时，我才会选择 A，并且为每个 webapp 复制公共库的开销变得非常大，或者我能够确保所有应用程序都使用相同版本的依赖项。然后，我知道依赖项可以安全地移动到应用服务器的共享区域中。

【讨论】：

有趣。我们完全控制服务器。您提出了很好的观点，但是想要避免在不同的 webapps 中拥有同一组件的多个版本呢？从 ops/mgmt 的角度来看，这不是一个理想的目标吗？我经常发现多个版本的 XML 解析器等，除了不气馁之外没有其他原因。
我同意你的看法——如果你能控制应用程序和服务器，那么就争取在 3rd 方库的版本上收敛。我使用 maven，这对此有很大帮助。即便如此，我将其视为版本管理问题而不是部署问题。所有应用程序都使用相同版本的库进行了测试，这意味着库可以共享，但版本管理必须首先为共享库铺平道路。
是的，我同意。我们使用 Maven 来管理它。但是有一些想法要转向单一战争，我们正在讨论是否值得改变，是否有其他人可能看到的好处。