Multiple ear files

Question

Lately at work we have been having a lot of discussion on the pros and cons of having one ear file for multiple projects or breaking the model down into multiple ear files. Its basically a portal environment with a lot of different portlets as separate projects. WSAD is being used for development while the project is deployed on WAS. Rach portlet is a separate WAR file packaged into the same EAR file.
The topic of discussion is incase one of the WAR files is changed whether
1) We should have a new build for the whole ear file.
2) Just update the one war file in the ear file.
3) redesign the whole thing so that each portlet rather than having a separate war file should have a separate ear file.
It is with this in mind that I am asking you gurus of your opinions and preferences. In case you could point out to some useful links that would be welcome too. I am sure you people would put in your ideas and it would be a good learning exercise for me.
Thanks

Answer 1

The pro is an absence of cons. If you don't needa
bunch of EAR files, don't make a bunch of EARfiles.
That simplifies deployment, tracking, management,
etc.But exactly the same arguement exists the other way
around.
deployment:-
If you have to deploy one module you donot have to
regenerate the whole ear file rather just building
this one ear file would do.Not on my watch. If any code changes you need to run
the acceptance tests again for the whole shebang. I'd
want ant to figure out which components get rebuilt,
not a human.
tracking:-
Since you are in control of which modules aredeployed
and each module is deplyed separately so you donot
need to do the regression test each time there is a
deployment. And you donot need to test the
fuctionality of the rest of the modules.Being in control doesn't mean you shouldn't run the
acceptance tests.
management:-
in case a bug is found in one of the modules onlythat
module could be replaced with a previous buildrather
than losing the changes in the rest of the modules.But you have to regression test everything else to
make sure that bug fix didn't break something else, or
that the bug fix is applied to every component that
shares the same source code.
Strive for more testing instead of less.as per the def of an ear file
An EAR is a deployment contract. Each EAR should represent a complete application and should not rely on code external to the EAR file, except what is provided by the application server itself.
so we donot need to run tests for the rest of the ear files and thats one of the benefits but what are the drawbacks?