If you run a program from Maven that produces stack traces, the logger will try to determine for every stack trace line whether source code is currently available in GlobalPathRegistry. This is bad for two reasons:

1. If there are lots of stack traces, output will be quite slow, much slower than running the same command from a shell. Better to pay the price for locating the source FileObject if and when the user actually clicks on it; do the minimum work when printing output.

2. Classes which _could_ have sources but do not have them at the time the stack trace is printed do not get hyperlinked. This is annoying because it is often the libraries you were not previously thinking about which are now implicated in an exception! Rerunning the program or trying to reproduce the exception is not always possible. You would expect that if a class from a closed project is hyperlinked but inaccessible, opening the project would let you try again. For a binary dependency, you would expect SourceJavadocAttacher to be tried.

OutputUtils.matchStackTraceLine seems to be at fault. I think the same problem applies to JavaAntLogger.messageLogged. JavaHudsonLogger is already fixed (1c70530ada72).

See bug #205359 for a suggested consolidated API, but fixing this issue at least for Maven should be easy: just move the body of 'if (match.matches())' into StacktraceOutputListener.outputLineAction, adjusting variables vs. fields accordingly; and add a call to SourceJavadocAttacher.attachSources if necessary (when the *.class can be located but *.java cannot). Can offer patch if you like.