当WAR的大小为41M时，如何避免在WAR中复制40M的java lib？
目前，我的构建过程包括使用WEB-INF / lib下的所有必需的Java库重新打包war文件，然后将war文件复制到由tomcat重新部署的开发/演示/生产服务器。
打包的war文件大小约为41M，目前它有40M的外部java库。 一定有更好的方法。 你是怎么解决这个问题的？
我的开发机器是一个Windows框，Eclipse作为我的IDE，Ant作为我的构建工具。 这些服务器都是带有Tomcat 5.5的Linux机器。
我是否应该将jar文件添加到服务器端的war包中？
我可以看到你在说什么，对我们的一些webapp也有同样的挫败感，但为了保持一致，我建议你保持原样。 如果将库复制到tomcat / lib目录，则可能会遇到系统类路径与webapp类路径的问题。
通过保持原样，您确信在开发/演示中部署与生产中相同的东西。 当你手动调整生产中的东西时，生活很糟糕，或者你有一些疯狂的错误，因为你忘记在生产中将版本1.6的XYZ.jar更新到1.6.1_b33，现在它的行为与你认为的完全相同的代码相同。
当使用足够重要的东西来开发dev / demo / production系统时，我认为一致性比.war文件大小更重要。
我们使用rsync工具（在我们的例子中，在windows下使用cygwin）将部署复制到服务器（运行linux）。 我们使用爆炸的WAR / EAR文件（即名为MyApp.war的目录结构而不是名为MyApp.war的zip文件），rsync只会传输已更改的文件。
在一般使用中，rsync将在大约5秒内传输30-40兆字节的爆炸EAR。
Tomcat有一个共享/ lib目录，它是全局应用程序依赖的适当位置。 但是，这些将对所有应用程序可见，这将影响依赖关系管理，并可能对静态变量等事件产生影响。 我不确定你是否可以在Tomcat中配置更好的东西。
另一种方法是切换到更复杂的Web容器。 例如，WebSphere Application Server Community Edition （ Geronimo的蓝色版本）支持每个资产库 。 其他免费和商业服务器也支持这一点。 我知道WebSphere Application Server ，我很确定你可以在Glassfish中做到这一点。
@McDowell，当提到那些J2EE服务器时，你应该确切地知道它们是J2EE服务器（servlet容器+其余的）。
就像@digitaljoel一样，我建议保留他们的样子。 看起来您还没有完成很多Web应用程序部署。 您将遇到的问题不值得（价格冲突，部署错误等）。
您是否可以将不变的Jars添加到服务器端的Java Library Path中，并且只在WAR中包含定期更改的Jars？
您可以在Tomcat / lib目录中包含外部Java库。 这样他们就留在了服务器上。
您可以将其部署为JAR文件，在本地复制部署环境，只需复制已更改的文件和jar本身。 路径是唯一真正的问题。
或者您可以考虑设置EAR。
我在开发服务器中使用“爆炸的Web应用程序”，偶尔也在生产中使用。 部署过程（基于ANT）使用我们的软件包更新WEB-INF / lib中的JAR。 只有在开发服务器中，我们才会激活Tomcat重新加载，它会在发生变化时重新启动应用程序。 您应该为这些Tomcats分配一些额外的永久内存，并有办法重新启动服务器，因为重新加载可能会不时崩溃Tomcat。
我知道这是一个奇怪的配置，但我无法理解如何不断重新打包30MB（并且不断增长）的典型应用程序可以做得更好。 可能有一天，开发描述符允许对容器可以下载和缓存的库进行外部引用。 ??
请原谅我可怜的英语。
您需要的是版本控制工具和构建过程。
使用CSV，SVN，GIT或任何适合您的方法来控制您的信号源。 使用构建工具来构建您的应用程序：Maven，ant，…
现在，当您想要在服务器上部署应用程序时，您只需在计算机上提交更新，在服务器上更新源代码，构建应用程序并从服务器部署它。
这样，服务器只需加载您的修改，它应该快得多。