----- Original Message -----
From: "Stefan Bodewig" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, July 25, 2001 7:44 PM
Subject: Re: Introduction of Multithreading
> On Sun, 22 Jul 2001, Conor MacNeill <[EMAIL PROTECTED]>
> 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
