2

Our web application has static content packaged as part of WAR. We have been planning to move it out of the project and host it directly on Apache to achieve the following objectives.

  • It's getting too big and bloating the EAR size resulting in slower deployment across nodes. Faster deployment times.
  • Take the load of Application Server
  • Host the static content on a sub domain allowing some browsers (IE) to load resources simultaneously
  • Give us an option to use further caching such as Apache mod_cache apart from the cache headers we send out to browsers.

We use yuicompressor-maven-plugin to aggregate and minimize JS file.

My question is how to package and manage this static content outside of the web application?

My current options are:

  • New maven war project. Still use the same plugin for aggregation and compression.
  • Just a plain directory in SVN and use YUI/Google compressor directly.

Or is there a better technology out there to manage static content as a project?

2
  • Have you considered a git set up, with the web server acting as a git remote to where you push your changes? Unless of course git is not an option. Something like this, possibly using post-receive hooks to trigger compression actions.
    – Boj
    Nov 4 '13 at 1:25
  • I've considered a direct SVN synced directory, then was wondering about the compression and aggregation. My main concern with the above approach is release process (I've not been through the linked article thoroughly yet). I will need to think of something like a staging area where developers can check in their changes without worrying about changes going live straight and release manager to be able to release quickly and without requiring too much knowledge about SVN/GIT etc.
    – chinto
    Nov 4 '13 at 3:32
1

It sounds like the static resources change rarely, if ever, and require significant additional space and time to process.

I would have a separate WAR file. There are several benefits to doing this:

  • You can easily hook into automated processes such as build servers, artifact repositories, and deployments. For example, you could add a Maven dependency to your parent POM and Jenkins can easily build and deploy the new project with minimal configuration changes.
  • The distribution file is still a single archive in a standard format. That makes it easy to maintain and easy to pass around if necessary.
  • You can update static resources and the web application independently, saving time for both when they update. Code updates do not require packaging a ton of static resources: resource updates do not require compiling code and running code unit tests.
  • By reusing existing deployment processes you maintain the same number of failure points while not increasing the training work load.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.