ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: [RFC] AbstractTasklet with extended functionality
Date Fri, 30 Jun 2000 15:23:47 GMT
At 05:06  30/6/00 +0200, you wrote:
>>>>>> "PD" == Peter Donald <> writes:
> >> Maybe I've misunderstood your proposal.
> PD> Nope. Your right there.
>I was afraid I would be.
>For those "other tasks", those not extending AbstractTasklet, would
>you want scripts to be able to work on them - setting/getting
>attributes? Or would you want the user to be aware that there are two
>kinds of tasks, those that you could manipulate and those you could

Well when we move to deferred tasks (if we do) then there is going to have
to be a rethinking on how scripting interacts with properties etc anyway.
So this point may be moot if we move to proxies. Depends on the
implementation strategy. As for scripts I have specifically created some of
these tasks so that I could do stuff declaratively rather than procedurally
so I am not sure scripting would be appropriate to them - Not sure.
Something to think about anyway.

>if (dir == null) {
>    throw new BuildException("dir attribute must be set on filesets");
>in whatever represents filesets.
>This is exactly the kind of validation you want to put into
>AbstractTasklet, isn't it?


>I'm not saying that a Validator class of some kind would be useless,
>quite the opposite. But put it to good use for the nested elements as

oh okay yup. I was thinking you mean all elements including targets etc :P


| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power."          |
|       -Abraham Lincoln                               |

View raw message