ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: svn commit: r439014 - in /ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/condition: antlib.xml
Date Tue, 12 Sep 2006 04:18:49 GMT
On Mon, 11 Sep 2006, Matt Benson <> wrote:

> Looks like this chain got out of hand and killed the discussion.

Might be related to the Subject line ;-)

> But we need consensus here on what to do before 1.7 final ships.

Yes.  We don't need consensus on how to deal with
newConditionOfTheWeek before the release, but on the use of
DynamicElement in ConditionBase.

I don't have any problem with ConditionBase (or AssertTask) not
extending Task, BTW.

> Background: My assertion is that we should no longer allow the
> proliferation of addNewConditionOfTheWeek() methods on
> ConditionBase; my (unorthodox as usual) solution was to allow
> business as usual in ConditionBase first: check for explicitly named
> addFoo() methods, then check for def'd conditions with
> add(Condition).

I'd hope that this was enough.

> The modification is to then implement DynamicElement in
> ConditionBase so that when the first two introspection methods fail;
> ConditionBase's DynamicElement implementation searches for a
> matching condition by prepending the
> ns to the element
> name and searching the Project's ComponentHelper for the
> corresponding definition.

Cool, but maybe too complex for this problem.

> Peter's suggestion to define as many conditions as we
> can competes with an earlier imperative to add new
> conditions only to the new condition antlib mentioned
> above.

Can't we have them both?  Add them to the new antlib and define them
inside of


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

View raw message