ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Reilly" <>
Subject Re: svn commit: r451000 - in /ant/core/trunk/src: main/org/apache/tools/ant/taskdefs/ main/org/apache/tools/ant/taskdefs/condition/ tests/junit/org/apache/tools/ant/
Date Fri, 29 Sep 2006 11:32:32 GMT
On 9/29/06, Antoine Levy-Lambert <> wrote:
> Hello Peter,
> -------- Original-Nachricht --------
> Datum: Fri, 29 Sep 2006 09:44:44 +0100
> Von: "Peter Reilly" <>
> An: "Ant Developers List" <>
> Betreff: Re: svn commit: r451000 - in /ant/core/trunk/src:
> main/org/apache/tools/ant/taskdefs/
> main/org/apache/tools/ant/taskdefs/condition/
> tests/junit/org/apache/tools/ant/
> > there are some issues remaining. I cannot find the e-mail,
> > but someone was
> > talking about needing to do some work-arounds for <condition> in
> > processing tasks in a nested sequential,
> it would be interesting to find out which problem this was exactly
> Was the email you are talking about the one from Alexey Solofnenko saying
> we cannot macrodef a condition ?

No it was steves .. see  his message.
The discussion was about using ConditionBase in antunit and the consequences
of doing this.
> You suggested to add an elements tag to macrodef. This seems cleaner than
> to say that condition are tasks and are allowed in the sequential element.

I am not trying to say that conditions are tasks...
It is the tasks that extend ConditionBase that cause the problem. As they
ConditionBase, they are not instances of oata.Task, but they are taskdefed
as tasks, so
ant provides an internal TaskAdapter to allow them to be used as tasks in
some situations.
The TaskAdapter has a pointer the the object instance, which gets used for
setting attributes
and elements, but not for other cases like references.

At one stage (for a few hours), <fail> extended ConditionBase to get access
to the conditions. I pointed out that this was not a good idea as 1) it was
not backward compatible 2) the resultant xml was a little ambigeous. The
solution was to have a nested element <condition> in <fail>, this nested
element extended ConditionBase.

> also a reference to a <condition> returns a TaskAdapter and not
> > a
> > Condition:
> >
> >      TaskAdapter ta = (TaskAdapter) getProject().getReference("cond");
> >      ConditionTask c = (ConditionTask) ta.getProxy();
> >
> Why does a reference to a condition return a taskadapter ? This sounds
> like a bug. Where is the faulty piece of code ? Was it like that already in
> Ant 1.6 ?

See above,  it is like this in ant1.6 and is true for all taskadapted tasks.
I am not
too sure if it is a bug.

> >
> > As there is not much benefit for the change, I can roll-back the change.
> >
> May be

Ok, I am convinced agree that it is not a good idea....
The reason is the example you provide in the ant-contrib example:
        <isset property="blue sky"/>
        <waitfor .../>

<waitfor> is not meant to be used as a condition (although it extends

In ant 1.8, all conditions will be resolved by using void add(Condition x),
so tasks that want to have nested conditions just need to extend Task and
implement add(Condition x).


> > Peter
> >
> >
> Antoine
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message