On 9/29/06, Antoine Levy-Lambert <[EMAIL PROTECTED]> wrote:
Hello Peter,
-------- Original-Nachricht --------
Datum: Fri, 29 Sep 2006 09:44:44 +0100
Von: "Peter Reilly" <[EMAIL PROTECTED]>
An: "Ant Developers List" <dev@ant.apache.org>
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.
http://marc.theaimsgroup.com/?l=ant-dev&m=115928696418366&w=2
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
extend
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:
<and>
<isset property="blue sky"/>
<waitfor .../>
</and>
<waitfor> is not meant to be used as a condition (although it extends
conditionbase).
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
> Peter
>
>
Antoine
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
