Dominique Devienne wrote:
I've been though a similar exercise with 50 developer separated over 9
countries contributing code over a period of just under 4 years. The final
result fell out into over 200 separate projects - each with specific build,
runtime and test dependencies.
Whoa, that's impressive! And I thought untangling 5000 classes in a
single project was a tough one... We only had 3 sites in a single
country.
you two scare me. What on earth are you writing that is so big? How do
you test it?
3. try and centralize properties away from projects
We use properties to direct which version of the dependencies to get.
A component declares its dependencies as just what it depends on, and
the build properties tell the system what version / branch of each
dependency to get.
This way, the same component can be compiled for two different apps
using different dependencies, because these apps are different
(release at different times for example).
I'm sure some people are cringing at what I just wrote ;-) Yes,
ideally a component is released, and then used by apps. Practically,
it didn't happen like this where I used to work, and too often last
minute changes were required of many components, and these changes
could have ripple effects on other components.
Its a bit like the fact that in a dist system you cant do a unified
upgrade -in a sufficiently complex project you cant upgrade in one go
because it forces stuff that is qualified as working to be requalified.
And if you use java classloaders right, you can get away with different
versions.
I use the maven2 tasks with a central libraries.properties file that
dictates for everything, but with each component having the ability to
override the global default with their own libraries.properties file.
the one thing we dont do is mix versions of things we release, because
it makes it harder to be flexible, and forces us to make our RMI
interfaces stable and our datatypes all with serial_UIDs. Instead
distributed nodes can pull down the latest (signed) binaries from http
servers on the fly; if you redeploy something in a new process it can
pick up the new binary.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
