Consider the following buildfile snippet: <junit> <batchtest todir="${project.build.test.reports}" fork="no"> <formatter type="plain" usefile="yes" /> <fileset dir="${project.build.classes}"> <include name="**/Test*" /> </fileset> </batchtest> </junit> This buildfile snippet runs all classes which begin with "Test" (in our project, all such classes inherit from JUnit's "TestCase" class) in JUnit. Some of our "public void test*()" methods in these classes spawn Threads; some of these spawned Threads print output to System.out. This output actually goes to console, and not to the <formatter>'s destination as the documentation states: "Output will always be sent to a file unless you set the usefile attribute to false". This also occurs in the 1.5 alpha (nightly) build on 04-11-02.
*** This bug has been marked as a duplicate of 5377 ***
Actually this is not really a duplicate of bug 5377. 5377 was concerned with output in the fork="true" case, which work now - with or without spawned threads. This one is a lot more difficult to tackle (to be honest, I don't know how). What we have here is that a test case spawns a thread in Ant's VM. Ant's output handling system doesn't know about the new thread and therefore will not pass the output to the junit task but send it to the logging system directly. As the <junit> task doesn'r receive the output, it cannot suppress/swallow it. If we simply pass all output to junit (by replacing System.out directly), junit will receive the output of different tasks when running inside <parallel> as well and label it as test case output. Bad.
Fixed by using ThreadGroups to track threads back to the owning task. Any chance you can retry with the code from CVS or the next nightly build?
I will try to try this from a nightly build, though I may not get to it until this coming weekend (2/15-16/03).