ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Duncan Davidson <dun...@x180.net>
Subject Re: [PATCH] Wait and Available (Updated)
Date Fri, 12 Jan 2001 06:22:34 GMT
On 1/8/01 7:38 PM, "Conor MacNeill" <conor@ebinteractive.com.au> wrote:

> 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");
> }

Yeah... One possibility is to capture System.out in some way -- it is a
settable variable on the System class.

Agreed that MT builds with Javac are going to produce bizzare output if
there are any problems with the compile... However, one possibility is to
give Javac an different ID depending on thread. So, when the compiler is
created:

sun.tools.javac.Main compiler =
    new sun.tools.javac.Main(jos, "javac:" + threadid);

Then buffer the System.out to somewhere.. If the task failed, it could say
"Javac task failed. Error lines dumped in following block. Messages from the
failed build begin with 'javac:threadId'". -- then after printing this, the
System.out buffer could be dumped.

Another possibility is that there will be a JSR to define how compilers
should work - an API for compiling iow. A long term solution to this problem
could be found there.

-- 
James Duncan Davidson                                        duncan@x180.net
                                                                  !try; do()


Mime
View raw message