GM> If you've got the time, would you outline the reasons for your GM> opinion?

Well, probably because "this is what I've ever done and it worked out well".

Most of the time my modules are not that self contained, they rely on common utility classes for example. If they were really separate beasts I'd probably put them into different CVS modules and not have a common master build file for them at all.

Given that my modules are connected in some way, I want to make sure that the latest versions of all modules work with each other - I don't want to remember that version 1.1 of module A works with version 2.0 of module B but not with version 2.1, but simply say module A of 2000-10-18 works with module B of 2000-10-18. Much the same reasons as the ones given in <http://www.martinfowler.com/articles/continuousIntegration.html#N157>.

To achieve this, I have a single common compileall target that will literally compile everything (with multiple javac tasks that have different classpaths containing servlet-api 2.0 or 2.2 and so on). Whenever I change a shared class I do an "ant clean compileall" and I will see the effects immediately.

And as I've said, *IMHO* it works better that way, but that doesn't mean a different approach would be inferior to mine, just that I've had very good experiences with my setup.

Stefan