This question is somewhat similar to this one Best way to deploy large *.war to tomcat so it’s a good read first, but keep on reading my q, it’s different at the end…
Using maven 2 my war files are awfully large (60M). I deploy them to a set of tomcat servers and just copying the files takes too long (it’s about 1m per war).
On top of that I added an RPM layer that’ll package the war in an RPM file (using maven’s rpm plugin). When the RPM is executed on the target machine it’ll cleanup, “install” the war (just copy it), stop and start the tomcat (that’s how we do things here, no hot deploys) and set up a proper context file in place. This all works fine.
The problem, however, is that the RPM files are too large and slow to copy. What take almost eh entire space is naturally the war file.
I haven’t seen any off-the-shelf solution so I’m thinking of implementing one myself so I’ll describe it below and this description will hopefully help explain the problem domain. I’ll be happy to hear your thought on the planned solution, and better yet point me at other existing solutions and random tips.
The war files contain:
- Application jars
- 3rd party jars
- resources (property files and other resources)
- WEB-INF files such as JSPs, web.xml, struts.xml etc
Most of the space is taken by #2, the 3rd party jars.
The 3rd party jars are also installed on an internal nexus server we have in the company so I can take advantage of that.
You probably guessed that by now, so the plan is to create thin wars that’ll include only the application jars (the ones authored by my company), resources and WEB-INF stuff and add smartness to the RPM install script that’ll copy the 3rd party jars when needed.
RPM allows you to run arbitrary scripts before or after installation so the plan is to use mvn write a list of 3rd party dependencies when building the war and add it as a resource to the RPM and then when installing an RPM the RPM installation script will run over the list of required 3rd party jars and download the new jars from nexus only if they don’t exist yet.
The RPM will have to delete jars if they are not used.
The RPM will also have to either rebuild the war for tomcat to explode it or add the 3rd party jars to common/lib or something like that although we have a few web-apps per tomcat so it’ll make things complicated in that sense. Maybe explode the jar by itself and then copy the 3rd party jars to WEB-INF/lib
Your input is appreciated 🙂
We have a directory on the target machines with all third party jars we’re using (about 110Mb). The jars are using a naming coding convention that includes their version number (asm-3.2.jar, asm-2.2.3.jar …). When adding a new version of a third party we don’t delete the older version.
When deploying, our jar files contains only business logic classes and resources we compile in the build (no third party). The classpath is defined in the jar manifest where we cherry pick which third party it should be using at runtime. We’re doing that with ant, no maven involved and we have more then 25 types of services in our system (very “soa” though I dislike this over buzzed word). That business logic jar is the only jar in the jvm classpath when starting the process and it is also versioned by our code repo revision number. If you go back to older revision (rollback) of our code that might be using an older third party jar its still going to work as we don’t remove old jars. New third party jars should be propagated to production machines before the business code that uses them does. But once they’re there they’re not going to be re-pushed on each deployment.
Overall we lean towards simplicity (i.e. not OSGi) and we don’t use Maven.