ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: Subdirectory problem/always recompiles
Date Mon, 21 Nov 2005 17:24:05 GMT
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 

I use the maven2 tasks with a central file that 
dictates for everything, but with each component having the ability to 
override the global default with their own 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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message