ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <co...@cortexebusiness.com.au>
Subject Re: Introduction of Multithreading
Date Wed, 25 Jul 2001 12:36:15 GMT

----- Original Message -----
From: "Stefan Bodewig" <bodewig@apache.org>
To: <ant-dev@jakarta.apache.org>
Sent: Wednesday, July 25, 2001 7:44 PM
Subject: Re: Introduction of Multithreading


> On Sun, 22 Jul 2001, Conor MacNeill <conor@cortexebusiness.com.au>
> wrote:
>
> > I have introduced the concept of a TaskContainer. This is an
> > interface. An object implementing this interface can have Tasks
> > added to it.
>
> Yes, but nothing else.  Why?
>
> What problems do you see with allowing arbitrary other child elements
> as well?  I mean apart from making TaskHandler.startTag a little ugly.

I was worried about the impact on the use of UnknownElements. If you look
at the code in TaskHandler.init, it is possible for a task handler to be
invoked even when a Task is not yet defined. So there is no easy way to
make the decision at that time about whether a particular nested element is
a task or nested element. The alternative, to try a nested element also
looked complex in the face of Unknown elements. I figured it was best to
make the decision early. There is no loss of capability as nested elements
can themselves be TaskContainers. So, you can have a list of tasks in one
nested element and other nested elements for other things

<foo>
  <tasks>
    <echo>
    <javac>
  </tasks>
  <classpath ...>
 </foo>

I see now, however, that you will not be able to taskdef TaskContainer
Tasks since the UnknownElement will not be a TaskContainer. I guess
RuntimeConfigurable.maybeConfigure will pick up the task container.

So, as you know this code quite well, I'd be interested to know your
thoughts on whether we should change it.

Conor



Mime
View raw message