Huge EAR deployment

I'm trying to figure out how to deploy a huge (40-50 MB) EAR file to the server through a rather slow VPN connection. The EAR contains EJB and WAR projects created in Glassfish, and 90% of the file size is from external dependency libraries used.

1. Has anyone came up with a strategy for elegant deployment to production system from Netbeans, where the deployment (over the network) is done only for what is really needed (i.e. just one WAR, not the entire EAR, or just one lib, not the entire libraries subprojec开发者_如何学JAVAt).

2. Related to the first point, how to separate external dependency libs from project in Netbeans, so that the project compiles on development machine, but when the EAR/WAR/EJB is created it does not contain all the dependency JARs, which are making it huge.

Perhaps we need to write custom ant script? Start using maven?

Thank you all for kind answers,

Bozo

Here's why it's a bad idea to move your dependencies out of an EAR and into a shared directory: by keeping all dependencies within the EAR, the app-server is able to cleanly undeploy/redeploy that EAR and reclaim the space that it used within the JVM heap (for Sun JVMs, the permgen). If you move some dependencies into a shared library, you run the risk that those dependencies will maintain a hard reference to some object defined within the EAR. This will mean that the EAR classes cannot be removed, and eventually your app-server will crash after running out of permgen space.

My suggestion of SSH based on the assumption that "VPN" mean Windows SMB, which has a lot of back-and-forth communication when copying files. Using SSH (or more correctly, SCP or RSYNC), you can use the full bandwidth of the connection.

If this is still too slow, you should look into changing your infrastructure. Since VPN implies corporate network to me, perhaps you can get a build machine set up on the same network segment as your deployment machine. From a process perspective, this is a far better idea anyway: you shouldn't be deploying builds from a developer workstation. Instead, you should check out the source into a clean environment, do a build, run tests, and then deploy.

An alternative is to see if your particular app-serve supports "exploded ears" -- if yes, then you just upload the JARs that have changed.

A reasonable approach might be building your EAR locally, and then use rsync to mirror the file over and then trigger a redeployment. As most parts of an EAR file do not change if the underlying jars do not change, you will get a big benefit from the rsync algorithm.

Why dont you copy your library jars to /glassfish installation dir/glassfish/domains/domain1/lib and dont package them into your ear file?