Duncan,
> Yes. System.out as used by tasks has to go away. Instead they should be
> sending message events that have Task/Target identification so that the
> output tool can sort the output appropriately. A convenience .message()
> method can be provided on the Abstract Task implementation that wraps a
> given message as an Event so that task writers don't have to worry about
> building Event objects everywhere.
>
Unfortunately the <java> task can execute arbitrary java classes that can
write to System.out. The <java> task contains two other facilities which
complicate matters. The class can be run in the ant VM (fork="no") and it
can redirect its output to a file. With those two combinations, the task
will effectively redirect the Ant VM's System.out to the file. That won't
work in a multithreaded model. In that case, we may need to allow a task to
know if it is being run in a thread. The java task could then do something
like
if (threaded && redirecting && not forked) {
throw new BuildException("Choose any two, baby");
}
Conor
