ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <Jan.Mate...@rzf.fin-nrw.de>
Subject AW: Guidelines for executing delegate tasks?
Date Wed, 02 Nov 2005 09:36:56 GMT
Sorry, just see now that you opened a bug [1]. I´ll have a look at that.

Jan


[1] http://issues.apache.org/bugzilla/show_bug.cgi?id=37328

>-----Ursprüngliche Nachricht-----
>Von: Jan.Materne@rzf.fin-nrw.de [mailto:Jan.Materne@rzf.fin-nrw.de] 
>Gesendet: Mittwoch, 2. November 2005 10:35
>An: dev@ant.apache.org
>Betreff: AW: Guidelines for executing delegate tasks?
>
>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
>  target.performTasks()
>  target.execute()
>  task.perform()
>  task.execute()
>
>
>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.
>
>
>Jan
>
>
>[1] 
>http://svn.apache.org/repos/asf/ant/core/trunk/src/main/org/apa
>che/tools/ant/Task.java
>[2] 
>http://svn.apache.org/repos/asf/ant/core/trunk/src/main/org/apa
>che/tools/ant/Target.java
>[3] 
>http://svn.apache.org/repos/asf/ant/core/trunk/src/main/org/apa
>che/tools/ant/taskdefs/Definer.java
>
>
>>-----Ursprüngliche Nachricht-----
>>Von: Jeffrey E Care [mailto:carej@us.ibm.com]
>>Gesendet: Dienstag, 1. November 2005 23:50
>>An: dev@ant.apache.org
>>Betreff: Guidelines for executing delegate tasks?
>>
>>All:
>>
>>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.
>>
>>Cheers,
>>JEC
>>--
>>Jeffrey E. Care (carej@us.ibm.com)
>>WebSphere v7 Release Engineer
>>WebSphere Build Tooling Lead (Project Mantis)
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org For 
>additional commands, e-mail: dev-help@ant.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message