ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: [PATCH] Nested Tasks
Date Thu, 01 Feb 2001 03:25:30 GMT

At 11:48  31/1/01 +1100, Conor MacNeill wrote:
>From: "Stefan Bodewig" <>
>> So let me chip in, even if I don't have a very strong opinion on it
>> either.
>> To me it's quite clear that asking, whether a TaskContainer concept
>> (I'd prefer that name as well) is desirable, boils down to "Do we want
>> to make it easier to write a foreach or a switch/case task?".
>Lets look, instead, at Thomas' motivation for the TaskContainer -
>multithreading of tasks. 

I think there is two different discussions going on. 
a) do we need/want TaskContainers
b) how do we parrelize (I assume that everyone is +1 to idea of parrallizing)

In regards to (a) then I think we need to look at the cost/benefit ratio.
In Ant2.x due to the usage of proxies/taskData containers/TOMs/whatever it
will be a low cost operation. The only cost comes to the developer who
actually writes the TaskContainer. With an applicable base class this could
even be minimised via an AbstractTaskContainer.

However in Ant1.x it comes at a steeper cost. I haven't looked at the
recent patch but if it was the same one submitted a while back then it does
cost a little bit. It added a bit to the complexity of the ant runtime and
a bit to general complexity of some task writers (though a minority). So in
Ant1.x it costs more.

What does it give us? It allows others (NOT us ;-]) to develope
if/then/else/switch/whatever with relative ease. They could take the ant
runtime and turn it into a general scripting language. While we shouldn't
condone it or accept such patches I don't see a problem with allowing this.
It could even gain us some developers/users from projects like xml-shell ;)

So the question is - do you think it is worth the extra complexity to allow
this? It could potentially harm our users in long run if they inadvertently
start using if/switch/whatever (thou it could also do good for small build
environments). Realize also that it will be a completely and utterly
unsupported in Ant2.x as it will do things differently.

Me I don't like the complexity and don't plan to help maintain it but if
there is people who are willing to do so then that is fine. I would not
veto it if we placed a "Danger Wil Robinson ! Danger !" sign indicating
that it is unsupported in future iterations. So I guess the overall would
be a +/-0 (Not much help am I ;-] )

With regards to parrelizing. I believe that the smallest user executable
action  is the target and should stay that way. Hence threading does not
belong at the task level but at target level. Hence I see something like

<target name="foo" async="true">

as better. But before we decide on the syntax we should first analyze use
case. Where will it be used and why will it be used. So far I have seen two
examples - "MUST NOT async", "MUST async" and "MAY async". 

The MUSTers involved your starting of web-logic server and then second
test-framework. The MAYers involved full utilisation of machine resources.
MUST NOTers are traditionalist where tasks have indirect dependencies (ie
files are generated etc). Have I missed anything or is there another use
case ?

Given this how do we build the syntax. As async is a feature of context
target is executed in we should be doing it at the level above where target
it is called IMHO. That is the only place where we can be sure of
dependencies. Hence I think the async belongs associated with depends tag
of target.

Possible solutions include an extra attribute 
async=Wont|Will|Can (with "wont" being default)

another solution involves having multiple versions of depends (ie
async-depends, can-async-depends and normal depends). However this relies
on user being aware that these options are mutually exclusive.

Anyways thats my take but I haven't followed the thread real close ;) 



| "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               |

View raw message