I ([EMAIL PROTECTED]) wrote:
> The key here is to consider what one wants out of a "project hierarchy".
> The sorts of things that I have had to do in the past are (I'm going to
> talk in "makefile" terminology, since that's what I've been using for C
> and C++ projects):
Let me be a little more precise about some of the things I was looking to be able to do:
* Define a common classpath in the master build.xml, but override it (either redefine, or augment) in the "client" build.xml.
* Define a common property in the master build.xml, and either override it, or augment it, in the client build.xml.
* Define a common set of rules in the master build.xml, but be able to redefine one or more rules in the client build.xml.
* Just like for a classpath, be able to augment or override fileset arguments to tasks.
* And finally, but definitely not the least, be able to be able to preserve all these semantics whether I launch the client build.xml directly, or from some master build.xml above (i.e. no surprise inheritance behavior).
I don't know much about the direction ant2 is taking, but even if it doesn't support all this out of the box, as long as there is a *way* to do all this (however clumsily), I'd be happy..
--
Shankar Unni.
