我试图弄清楚如何通过相当慢的 VPN 连接将一个巨大的 (40-50 MB) EAR 文件部署到服务器。EAR 包含在 Glassfish 中创建的 EJB 和 WAR 项目，90% 的文件大小来自使用的外部依赖库。
有没有人想出一个从 Netbeans 优雅地部署到生产系统的策略，其中部署（通过网络）只针对真正需要的东西（即只有一个 WAR，而不是整个 EAR，或者只是一个库，而不是整个图书馆子项目）。
与第一点相关，如何在 Netbeans 中将外部依赖库与项目分离，以便项目在开发机器上编译，但是在创建 EAR/WAR/EJB 时它不包含所有依赖 JAR，这使得它变得庞大.
也许我们需要编写自定义的 ant 脚本？开始使用maven？
谢谢大家热心解答，
博佐
这就是为什么将您的依赖项移出 EAR 并进入共享目录是一个坏主意的原因：通过将所有依赖项保留在 EAR 中，应用程序服务器能够干净地取消部署/重新部署该 EAR 并回收它在JVM 堆（对于 Sun JVM，permgen）。如果您将一些依赖项移动到共享库中，您将面临这些依赖项将维护对 EAR 中定义的某些对象的硬引用的风险。这意味着不能删除 EAR 类，最终您的应用服务器将在 permgen 空间用完后崩溃。
我对 SSH 的建议是基于“VPN”表示 Windows SMB 的假设，它在复制文件时有很多来回通信。使用 SSH（或更准确地说，SCP 或 RSYNC），您可以使用连接的全部带宽。
如果这仍然太慢，您应该考虑更改您的基础架构。由于 VPN 对我来说意味着公司网络，也许您可以将构建机器设置在与部署机器相同的网段上。从流程的角度来看，无论如何这是一个更好的主意：您不应该从开发人员工作站部署构建。相反，您应该将源代码签出到一个干净的环境中，进行构建，运行测试，然后进行部署。
另一种方法是查看您的特定应用程序服务是否支持“爆炸耳朵”——如果是，那么您只需上传已更改的 JAR。
一种合理的方法可能是在本地构建您的 EAR，然后使用 rsync 镜像文件，然后触发重新部署。由于如果底层 jar 不更改，EAR 文件的大部分部分都不会更改，因此您将从 rsync 算法中获得很大的好处。
为什么不将您的库 jar 复制到 /glassfish 安装目录/glassfish/domains/domain1/lib 并且不将它们打包到您的 ear 文件中？