ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Louis Tribble <>
Subject Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Date Wed, 16 Jan 2008 17:48:18 GMT
Dominique Devienne wrote:
> On 1/16/08, Gilles Scokart <> wrote:
>> I was just saying that Ant benefits/(or suffer...) from great flexibility,
>> and you should not change that. [...]
> I agree with Xavier, control in large build system is a very desirable
> feature, if only to force developers to talk to the build team to ease
> restrictions at times, for example.
Very much. We know we haven't anticipated everything, but
our old build system--with few restrictions and little prescribed
structure, and everybody piling on--was on the point of collapse,
even though the system was a lot smaller then. Individual module
developers may not even be aware of the design goals and invariants
of the build system, and even if aware, don't necessarily have any
incentive to go out of their way to preserve them. (The engineers
involved in the new build system were and are just developers
with other responsibilities who got fed up with the old system,
spending time policing checkins for signs of rot was never an
> Final methods and classes in Java are not used often, but they are
> essential for some patterns, and no one forces you to use them.
> So no, dismissing a feature useful to some, when you are not forced to
> use it, is not a position I find OSS friendly. For example, I wasn't
> at first particularly favorable to genericantfile in <subant>, which I
> consider a bit my "baby", yet it was quite useful to some, and they
> provided patches, so who am I to dismiss their use case?
What prompted me to speak up is that right now, the way imports
and overriding work, we at least have some control, and I was concerned
to lose even that. The module-specific overriding targets are imported 
the mandatory targets are defined but before the empty default before and
after targets are defined, so a module can override the before and after
targets but not the mandatory targets. My concern is that a generic
override feature will undermine the restriction.
> So hint hint Louis, patches for your proposed extension-restricting
> features useful in large corporate build setting are more than welcome
> ;-)))
I'm not optimistic, but I'll try... Right now, if I contribute anywhere,
it should be to the JUnit tasks, probably. I've been bumping up against
them a lot.

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

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

View raw message