If an error occurs that seems unfamiliar, the first step is to examine the output of the build.
This can be as simple as looking for the last goal executed. In the event that the error message is not clear enough, we will at least know what Maven was running at the time it occurred, and can jump to the plugin web site for information on the possible cause, or at least configuration options that will alter the behavior or output of the plugin (such as the verbosity level) to help troubleshoot.
However, often the error is not that simple, and finding the cause in a large amount of output is difficult. Two steps can be taken to make this part easier.
Firstly, you can scan the output for the [WARN] or [ERROR] prefix. While not always used, anything logged at this level by a Maven plugin may indicate a problem. If you prefer not to scan the output, you can also run Maven with the -q option. This is an extremely quiet mode of operation, logging only warnings, errors, and messages output directly to the system by plugins.
A more reasonable measure you can take in advance is to reduce the amount of output during the build. This has a number of side benefits, such as reducing the size of build results in a continuous integration server, but more importantly helps you see what is really happening in the build. A key offender in the area of build output can be unit tests. As they often do their own logging or produce their own output, this may appear during the build rather than just receiving the test summary.
However, Surefire has a configuration option to remedy this by channeling all of the output into a separate file for each test. It can be configured like this:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.4.3</version>
<configuration>
<redirectTestOutputToFile>true</redirectTestOutputToFile>
</configuration>
</plugin>As simple as this step seems, it can be of great benefit in maintaining your build without any loss of information.
Tip
Of course, another option that gives greater control is to avoid the use of the System.out and System.err streams in your test cases, and to configure the logging system used by your code to be as silent as possible, or to write to a file directly.
A final note on Maven output: don't be misled. There are some plugins and even internals of Maven that will report a [WARN] or even [ERROR] message where the behavior is actually correct but it is trying to communicate something that may only potentially be a problem, or is actually a programming fault. Review each message carefully to see if it is the cause of a problem rather than assuming that it is by the label.