ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <stev...@iseran.com>
Subject Re: AW: [PATCH] Wait and Available (Updated)
Date Mon, 15 Jan 2001 20:44:17 GMT

----- Original Message -----
From: "Peter Donald" <donaldp@apache.org>
To: <ant-dev@jakarta.apache.org>
Cc: <ant-dev@jakarta.apache.org>
Sent: Saturday, January 13, 2001 11:20 PM
Subject: Re: AW: [PATCH] Wait and Available (Updated)


> At 03:52  13/1/01 +0100, Thomas Christen wrote:
> >> If there was a separate interface for logging (called say Logger)
> >Well I did it a bit different. I was thinking rather of a logging
strategy
> >at task level.
> ...snip...
>
> um - you do realize that you do everything from this example via
> BuildListener/BuildLoggers ?
>

The nice thing about having a separate interface for logging (Like Thomas'
with a getOutputStream() method) is that classes which are not derived from
Task can talk to the current log without having to know about their owning
task.

Right now you end up having to carry a task reference around, often a couple
of levels deep just for the logging facility. Example:
(taskdefs.optional.dotnet.NetCommand holds onto a Task to pass to the
LogStreamHandler constructior )

If we had a separate interface then that is all that needs to be passed
in -or assigned to a TaskExecutionHelper which gets passed round. Then when
you parallelise code then it becomes easy to change the logger. But looking
at where the changes would need to go they are pretty 'deep'; not quite
Ant2.0 class of change, but probably an Ant1.4

NB: .Thinking of stuff to put into a TaskExecutionHelper class, there
another item that springa to mind is a touch(Date) method that obviates
having to create a new Touch task.

-Steve



Mime
View raw message