ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject AW: Guidelines for executing delegate tasks?
Date Wed, 02 Nov 2005 09:35:08 GMT
Hello Jeffrey,

as far as I can see
- the perform() method is called by Ant and
- the execute() is implemented by the taskwriter.

Usually you are overwriting the Task.execute() method - which has an 
empty implementation in Task [1]. The Task.perform() does event firing
(task starts/ends) framework internal configuration and calls the execute()
method. So overwriting this method seems to be the "right" way.

Coming from my idea that a project holds several targets the project should call
a method from the target to perform all the tasks work. So I did a look at
Target [2]. There are two methods: performTasks() and execute(). The perform does
only event firing (target starts/stops) and calls the execute() method. That method
iterates over all tasks and calls that perform() method!
So the stack is

Now lets have a look at the Definer task [3] ... öh ... is this the task you mean?
What would your patch be? Maybe you could send it to the list.



>-----Urspr√ľngliche Nachricht-----
>Von: Jeffrey E Care [] 
>Gesendet: Dienstag, 1. November 2005 23:50
>Betreff: Guidelines for executing delegate tasks?
>I've recently encountered some difficulties with the 
>multithreaded build extensions that I've mentioned on the list before. 
>As part of the Mantis project that we use to build WAS we have 
>a custom logger. This logger uses a different banner format 
>([project/target/task]) from the default logger. The current 
>problem is that the banners on messages from the sub-builds 
>have the wrong context information; specifically they either 
>no context (i.e. the banner is empty) or they have the parent 
>project's context.
>I've done a lot of debugging in the past few days and found 
>that the parent context bit is due to a bug in our code, so 
>mea culpa there. But the no context bit I traced to some code 
>in oata.taskdefs.Definer. Definer creates an Antlib task 
>instance to load our antlib. Now, creating a "delegate task" 
>is a fairly common pattern; I do it in Mantis a lot. The 
>problem (as I see it anyway) is that Definer calls "perform" 
>instead of "execute" to make the Antlib instance do its work.  
>Because "perform" is used that blows away the currently 
>registered task for the current thread. 
>I've overridden Definer locally to call "execute" instead of 
>"perform" and my problems seem to have cleared up with no 
>side-effects. (Also interesting that this isn't really 
>threading related - it happens even when everything is running 
>on the main thread.)
>So, getting to the point, is there a general policy regarding 
>"execute"/"perform" for delegate task instances? Based on my 
>experience I would think that "execute" would be preferred, so 
>I wasn't sure if "perform" was required in this instance. I've 
>prepared a patch for Definer, but I didn't want to open a 
>bugzilla report until we had some discussion here on the list.
>Jeffrey E. Care (
>WebSphere v7 Release Engineer
>WebSphere Build Tooling Lead (Project Mantis)

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message