ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Devienne <>
Subject Re: Subdirectory problem/always recompiles
Date Mon, 21 Nov 2005 15:35:15 GMT
> 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

>  1. a strict file structure per project is invaluable

I have to agree, although I took a different tack. I didn't "break"
the project into several projects, I created a build that enforces the
dependencies within a single source tree. Much less disruptive. This
project was only one of the "macro" modules going into different apps
(the main infrastructure one).

>  2. centralize version and dependency information away from
>     the logic related to build mechanics

I started out that way within the project (XML dependency meta-data
XSL'd into a build file), and later refactored to use a pure Ant build
approach when macrodef was introduced.

But in general I like to keep dependencies at the component level, and
the dependencies are recorded with the published component. We haves
several branches of the same component that may (and often do) have
different dependencies, so keeping this in a central place becomes a
management issue. I prefer a loose "federation" of components.

What I kept central is the fixed meta-data about a component like
where in CVS it came from, contact information, build file name,

>  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.

I guess it's more an app broken into several macro components that can
be reused by other apps, rather than true component development...

>  4. put in place a modularization strategy that groups projects
>     together - that preferably captures property inheritance
>     and build strategy independently of the build mechanisms

I also agree with grouping. You don't want to publish 200 independent
components. Better to publish 10 or 20 regrouping logically related

We did some grouping were components built independently were later
aggregated by a single macro component to higher level stuff to use
(rather than the individual components). The app itself ends up being
just that, a build that aggregates all necessary components, shuffles
them a bit, and creates an install of it.

>  5. make extreme efforts to eliminate information in a build
>     file - preferable to the point where a build file is not
>     even required (i.e. the build.xml only contains information
>     that is 100% specific to the project)

I actually put dependency information in the build file itself, in
custom types later used by the custom tasks gathering the dependencies
and constructing paths out of them. And in the case of this project
were I untangled the dependencies, the info that "declares" each
independent sub-part of the project lives in a separate target, in a
macrodef used to compile that part. All very ad-hoc really, but
physically breaking up the single source tree into 20 source trees
wasn't an option.

So all in all, I pretty much agree with you, but pragmatic or
historical considerations often makes the ideal compartmentalization
of code impractical. I'm glad to hear you were able to take the high
road, but I'm not sure how many shops do take it.

Sorry for the long winded comments. I guess I want to record this
stuff before I forget it all, since I no longer work there ;-) Thanks
for sharing your experience.


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

View raw message