On 9/29/06, Antoine Levy-Lambert <[EMAIL PROTECTED]> wrote:

Hello Peter,

I would like simply to understand why you did this change. What does this
bring us ?

A class that does not have an execute method is semantically not a task.
So I would also say that such a class should not extend Task.


There are a number of tasks that extend conditionbase - <condition>,
<waitfor>, and the <ac:if> task.
They do cause some issues - ant 1.7 had addresses some of these by adding
taskname and location
information, but 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
sequenial, also a reference to a <condition> returns a TaskAdapter and not a
Condition:

    TaskAdapter ta = (TaskAdapter) getProject().getReference("cond");
    ConditionTask c = (ConditionTask) ta.getProxy();


Can we find a way to get whatever you want to achieve by this change in a
way which makes sense semantically ? I remember we were discussing before
about maybe declaring conditions with typedefs. Would this be something
which would address your concerns ?


No,  this is a dirrerent issue.

Regards,

Antoine
-------- Original-Nachricht --------
Datum: Fri, 29 Sep 2006 05:31:10 +0200
Von: Stefan Bodewig <[EMAIL PROTECTED]>
An: 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/

> On Thu, 28 Sep 2006, <[EMAIL PROTECTED]> wrote:
>
> > Make conditionbase a Task.
> > ?was there any reason that this was not done for ant 1.6?
>
> When I brought the whole condition eco-system into 1.4, I decided
> against extending Task because some of the conditions themselves
> extend ConditionBase as well.  When you make ConditionBase extend Task
> this suddenly turns <and>, <or> and <not> into tasks.


Only if they are typedef'ed.


> I also don't think it's a good idea to extend task but not provide an
> implementation of execute().


True, but the implementation of execute() can be to do nothing - i.e. treat
me as a type, or process everything in addConfigured() callbacks.


> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


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

Peter


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to