Maven - 部署大型战争文件

Question

这个问题有点类似于这个问题Best way to deploy large *.war to tomcat所以这是一个很好的阅读，但继续读我的q，最后它是不同的......

使用maven 2我的war文件非常大（60M）。我将它们部署到一组tomcat服务器，只是复制文件需要太长时间（每次战争大约1米）。

最重要的是，我添加了一个RPM层，它将战争包装在RPM文件中（使用maven的rpm插件）。当在目标机器上执行RPM时，它将清理，“安装”战争（只需复制它），停止并启动tomcat（这就是我们在这里做的事情，没有热部署）并设置一个适当的上下文文件地点。这一切都很好。
但问题是RPM文件太大而且复制速度慢。几乎整个空间几乎都是战争文件。

我还没有看到任何现成的解决方案，所以我想自己实现一个，所以我将在下面描述它，这个描述有望帮助解释问题域。我很高兴听到您对计划解决方案的想法，并且更好地指出了其他现有解决方案和随机提示。

战争文件包含：

1. 应用程序罐子
2. 第三方罐子
3. 资源（属性文件和其他资源）
4. WEB-INF文件，例如JSP，web.xml，struts.xml等

大部分空间由第3方罐子＃2拍摄 第三方罐子也安装在公司内部的nexus服务器上，所以我可以利用它。

你可能已经猜到了，到现在为止，计划是创建只包含应用程序jar（我的公司创作的），资源和WEB-INF的瘦战争，并为RPM安装脚本增加智能性必要时会复制第三方罐子 RPM允许您在安装之前或之后运行任意脚本，因此计划是在构建war时使用mvn编写第三方依赖项列表并将其作为资源添加到RPM，然后在安装RPM时RPM安装脚本将运行在所需的第三方罐子列表中，只有当它们不存在时才从nexus下载新的罐子 如果不使用，RPM必须删除罐子 RPM还必须重建tomcat的战争才能将它爆炸，或者将第三方jar添加到common / lib或类似的东西，尽管我们每个tomcat都有一些web应用程序，因此它会使事情变得复杂。也许可以自己爆炸jar然后将第三方罐子复制到WEB-INF / lib

感谢您的意见：）

Answer 1

我会反对你提议的计划。这听起来像许多移动件，当它们出现时很难测试和/或诊断问题。

我们没有“大型”WAR的问题，但我们确实遇到的问题是，我们的大多数WAR都需要在其类路径上使用完全相同的第3方库。我们提出的解决方案（效果非常好）是利用OSGi模块化地构建我们的应用程序。我们使用Felix作为我们在Tomcat内部运行的OSGi容器。然后，我们将所有依赖项/库部署到Felix 一次。然后我们通过从它关心的bundle中导入它需要的包来部署“瘦”WAR，它只引用OSGi依赖。

这还有其他一些优点：

• 在旧版OSGi捆绑包运行时部署新版本的OSGi捆绑包不是一个不会导致停机的问题（类似于热部署）。
• 如果你需要升级你的一个依赖项（例如Spring 2.5 - > 3.0），你只需要升级在OSGi中运行的Spring包;如果API没有改变，则无需交付（或打包）新的WAR。这可以（再一次）在一个正在运行的OSGi容器上完成，不需要关闭任何东西。
• OSGI保证您的捆绑包不共享类路径。这有助于保持代码更清晰，因为每个WAR只需要知道它关心的内容。

将WAR设置为“OSGi就绪”并非易事，但它已有详细记录。尝试查看How to get started with OSGi或仅查看Google以获取第三方教程。相信我，初期投资将为您节省大量时间和未来的许多麻烦。

如果可能的话，最好不要重新发明模块化轮。

Answer 2

我们在目标计算机上有一个目录，其中包含我们正在使用的所有第三方jar（大约110Mb）。这些jar使用的命名编码约定包括它们的版本号（asm-3.2.jar，asm-2.2.3.jar ...）。添加新版本的第三方时，我们不会删除旧版本。

部署时，我们的jar文件只包含我们在构建中编译的业务逻辑类和资源（没有第三方）。类路径在jar manifest中定义，我们在那里挑选它应该在运行时使用的第三方。我们用蚂蚁这样做，没有maven参与，我们在我们的系统中有超过25种类型的服务（非常“soa”虽然我不喜欢这个嗡嗡作响的词）。该业务逻辑jar是启动进程时jvm类路径中唯一的jar，它也是由我们的代码repo修订版号版本化的。如果你回到我们的代码的旧版本（回滚），可能正在使用旧的第三方jar，它仍然可以工作，因为我们不删除旧的jar。新的第三方jar应该在使用它们的业务代码之前传播到生产机器。但是一旦他们在那里，他们就不会被重新推动每次部署。

总的来说，我们倾向于简单（即不是OSGi），我们不使用Maven。