pros and cons of separate war files

Question

I'm somewhat new to the java landscape and have some questions about best practices for architecting a web portal. So my question is really is there any advantage to breaking a gigantic war file into smaller war files. The only ones I could come up with:

• Modularity: it allows for separate developers to work on separate parts of your site and deploy them separately.

• Organization: it's easier to find portions of your site if they aren't in the same code base.

• Scalability: This only makes sense to me if you are going to be deploying portions of your site on different web servers. If they are all being deployed to the same front-end servers is there any advantage?

From what I have read, it seems most folks seem to think one big war file is the best way to go: avoid redundancy, one step deployment, etc. So are there reasons to break it up? Maybe anonymous/brochure version of site vs authenticated?

Answer 1

Few things you need to consider that can highly influence your decision:

1. Different dependencies - let's assume class A requires a library L of v1, and class B requires the same dependency, only a different version - v2. If you deploy both on the same war, they will get the same classpath, and you must align all the dependency versions. If you split them, you can have v1 on one war, and v2 on the other. It also means that if you want to upgrade from v1 to v3, you only need to test class A behavior, as class B will remain with the old version. So modularity here is very powerful.
2. Load time of the server - the more war files you have, the more time it will take for the server to start.
3. Maintenance - war files tend to be bloated, unless you keep a close eye on the size and remove redundant dependencies - not an easy task! some are runtime dependencies, some compilation, some for tests, some for production. It's a lot of work, and people tend to postpone it. If you have one bloated war file, with X redundant dependencies, that's an X sized problem (time of load, storage wasted to keep each version etc.). If you have Y war files, than your problem is X*Y size.
   In other words - it's easier to clean up a 1 bedroom apartment, than a 7 bedroom villa.

Answer 2

If there are separate scalability, security and reliability requirements for certain modules then you can break them up. Ideally your security can be separate if needed.

Answer 3

Operations folk prefer one big .war, because it means there's just one thing to deploy.

However, if you can comfortably break up your web site into separate .wars, and honestly deploy and un-deploy them without affecting the other deployed artefacts, and are certain you need this granularity (see YAGNI), then break it up.