ant-dev mailing list archives

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