some execution output not routed through default routes.

should we re-route system streams to logger, just to guard against plugins doing Bad Things again?

scanning all the current plugins, etc. may fix this issue for now, but any new plugin (or subsequent update to existing plugins) can re-break it.

I'm not sure that would be wise - when runningin another application (e.g. an IDE) I wouldn't want Maven to fiddle with external resources such as streams. What if the IDE wants to reroute the system streams to another source?

I think this should be solved by imposing some other form of validation on the source (perhaps a checkstyle check that fails the build if it finds a System.out?)

I think surefire should be fixed in the later plugins - can you confirm?

brett, which version of surefire do you mean?

surefire plugin 2.2 (surefire 2.0)

still doesn't seem to work for me. when running the build in the IDE, I get the surefire output in the console where I started the IDE from, instead the output window. please note that if you do a System.out in a maven build somewhere, the IDE is capable of catching that one even though it's not routed through the loggers. but with surefire's forking, it's all lost.

brett: I've done some additional debugging of the surefire plugin problem and I tracked it down the StreamPumper classes that print messages from the forked process to the System.out of the IDE's process. However the delegating System.out impl in the IDE doesn't recognize these threads (StreamPumper is a running thread) as belonging to build being executed and prints them to console. I believe it's because the threads don't belong to the same ThreadGroup. I tried to confirm the theory but surefire cannot be used with the trunk version of plexus-utils.

please note that even when this is fixed, it still doens't fully satisfy the issues mentioned in this report. In the ideal case one should get the output in the logger/llisteners, which is not the case now and it will only be cought by the IDE's safety net. But it cannot be filtered out, have actions attached to it etc..

After some more work I think I got it working for netbeans correctly. The StreamPumper not printing was a Netbeans/Mevenide classpath issue.
Now I have a multiplexing stdout/stderr implementation that is capable of sending the System.out and System.err to the correct output window pane.

not sure if we can consider the issue fix as the texts are not routed thought the loggers but System.out.

Milos has figured this out in netbeans using a multiplexing solution in netbeans. This is really a bigger in issue where a set of threadsafe components are not logging to the originating thread but for the time being this issue has been resolved for netbeans.

but if this works for netbeans doesn't it still need to be fixed for anything else using the embedder? I'm not sure it should be closed.