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

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

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

我没有看到任何现成的解决方案,所以我正在考虑自己实现一个,所以我将在下面描述它,这个描述将有助于解释问题领域.我很乐意听到您对计划解决方案的想法,并且更好地指出其他现有解决方案和随机提示.

战争文件包含：

>应用罐子
>第三方罐子
>资源(属性文件和其他资源)
> WEB-INF文件,如JSP,web.xml,struts.xml等

大部分空间都是由第二方罐子#2拍摄的.
第三方罐子也安装在我们公司的内部nexus服务器上,所以我可以利用它.

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

您的意见赞赏:)

最佳答案 我们在目标机器上有一个目录,其中包含我们正在使用的所有第三方罐子(大约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.