different WAR files, shared resources

Question

Suppose you have several applications which share the same code and most of the other resources, but have a somewhat different look and feel, some labels change, etc. (think branding). If each web app is to go in its own WAR file, where do you put the shared resources?

I already use the classpath to share classes and property files. But what about javascript and css files? Is the best way to create and deploy one extra WAR file that will serve these shared files to whatever other application requires them?

I also thought of a build script that does some magic and from a common source spews out the (slightly) different WARs, but I don't like it because it just complicates stuff unnecessarily when you need to build/test/run a single application.

Any other tips and tricks would be appreciated.

Answer 1

A strategy that I have seen used for such product-line like configurations is using WAR overlays when building with maven. You define a common WAR that contains the common stuff and overlay it with those other WARs that contain the specific stuff to generate different WARs for every application. This method is probably most useful if you deploy the WAR-variants on different machines. But I'm not sure whether I can actually recommend this.

Remember to specify the overlays configuration if you actually override stuff, since otherwise the overriding order is not deterministic. It might even change with a maven-war-plugin upgrade. (It did in our case.)

Answer 2

How about putting your css and js in the classpath and serve them with a servlet? Then you can build the common resources as a jar and that jar can even contain the servlet (resource dispatcher if you like) and the war files can contain the jar file in the WEB-INF/lib folder.

Answer 3

You can deploy both WARs in the same EAR and put common resources in the EAR. Then put the appropriate dependencies in the manifest of the web apps to link to the jar files in the ear.

Answer 4

If you don't want to go the EAR route, using tomcat, etc; there are a few other ways to achieve the consistency you want.

If you want to share just js and css, look into pack:tag. You could host the .js and css from an apache server, set up your httpd.conf so your webapps can call it, then use pack:tag from your application wars - DRY and compression in one step.

Answer 5

Thanks for the replies so far, but I'm afraid I forgot to mention that the WARs will be deployed in different environments that are completely isolated from each other.

So maybe having a common WAR deployed next to the actual application is the only option. I think I'll go with the following:

• WAR1, WAR2 containing app-specific stuff
• CommonWAR containg common stuff (no kidding)
• EAR1: WAR1 + CommonWAR, to be deployed in env1
• EAR2: WAR2 + CommonWAR, to be deployed in env2

Answer 6

Update

Yes, me again. I have actually changed my mind (again :) ). I am currently trying (being more prudent here):

• (Common)WAR: containing the application, common (most part) + some specific stuff
• EAR1: CommonWAR + specific configuration file for env1
• EAR2: CommonWAR + specific configuration file for env2

The configuration file is picked up by the WAR. It is on the the EAR classpath and only contains one property 'application' with a value. The single WAR will then use this information where appropriate to distinguish between the two apps (config, style sheets, ...).

With my solution of EAR1 = CommonWAR + WAR1, EAR2 = CommonWAR + WAR2, it was too difficult or impossible to lookup static resources in the CommonWAR without using a web url (e.g. images in PDF documents generated with iText).