ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: executing task for each file in file set
Date Mon, 18 Jun 2001 09:45:33 GMT
On Mon, 18 Jun 2001 19:30, Stefan Bodewig wrote:
> >> At some point during discussion about Ant2 we've more or less
> >> agreed that there'll be an antcall version that doesn't use an
> >> execution context of its own - so that would cover (a) as well.
> >
> > Did we agreed to that? I thought we were talking about nested
> > <tasks>, but not about some other <antcall> behaviour.
>
> Maybe my memory is failing as I cannot find it in the list of accepted
> features either.

I think it was kinda accepted ... but I think I have changed my mind ;)

> We will have to deal with this problem in the context of
> multi-threaded execution of tasks in a target anyway.  This probably
> means that bigger parts of the core need to be redesigned for
> multi-threading and that we document side-effects of some tasks
> properly (so people know when they are going to get themselves into
> trouble).

The only real problem I have identified so far is the ProjectListener 
interface. Usually it assumes a serial set of event, but with parralelism it 
becomes difficult to decide how to arrange event dispatching system. I 
haven't been able to think of a nice way of "fixing" this.


> > Yeap, nested constructs are powerful. But if we go that way, what
> > stops us from having the same argument about <if><else> (or maybe
> > <choice><case></choice>) type of constructs?
>
> Who said we wouldn't have these arguments?
>
> We are going to allow container tasks anyway - we need them for the
> multi-thread implementation like we've currently planned it.  I'm sure
> somebody will create choice/switch/select/if/whatever tasks based on
> this construct - and I think this is OK.  If you feel you need an if
> task, the container task way lends itself to it.

I am fairly sure I will create at minimum an if task but it highly unlikely 
to be put in ants core ;)


> > In ANT we have come up with a pattern for calling a subroutine which
> > is based on <antcall> and the definition of <target>s.
>
> Have we?
>
> [targets as methods]
>
> > Should we have it, should we not? What should be the principle
> > behind our answer?
>
> Well, to dogmatically answer the first. No! Just see the vote for Ant2
> features, it has been vetoed by no less that five committers.
>
> I don't have a less dogmatic answer at this time - I need to get some
> things sorted out before I can come up with one.

The more I have prototyped this the less I see the need for it. See my "do we 
need antcall" question a bit back. Reusable chunks should sit at a different 
layer.

Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*

Mime
View raw message