Avoid creation of emailable-report.html when using Maven, Surefire and TestNG

The problem

Last week, my Eclipse ran into a lot of “java.lang.OutOfMemoryError: Java heap space”-errors, telling me about that incidence (using a pop-up) and asking me if I really want to work on with my workspace (using an additional pop-up) again and again. Coding became hardly practicable so I started to search the cause of this failure.

What was the problem? The html-validation plugin of Eclipse tried to scan a file called “emailable-report.html” inside the target-directory (more precisely: in the directory target/surefire-reports). That directory had been created by m2eclipse but a simple “mvn clean install” created it, too.

Having a closer look on emailable-report.html with my favorite file manager I couldn’t believe my eyes: that file had a size of 440MB! I also found an emailable-report.html in every projects target folder inside my workspace, some smaller, some larger. The largest: 1.4GB—and by the way—who sends reports with that size via email?? I opened one of these files with a text editor and found the test results of the TestNG-tests, which are executed on a Maven build. Depending on a large set of test data (here: thousand of useragents) those files were blown up with information.

So the html-validation plugin simply crashed because of a (very) large html-file.

The solution

At first I blamed the Maven Surefire plugin for creating the reports but couldn’t find an option to turn off this behavior. In fact I even didn’t find a relation between Surefire and the emailable-report.html. And that’s the point–those files aren’t written by Surefire, they are written by TestNG itself! After googling a while I got to the property “usedefaultlisteners”. Unfortunately, it isn’t specified in the main TestNG-manual but in the TestNG-Ant manual. However, negating this option will shut down the result-writing (as well as all other default listeners).

So I added the following to the Surefire configuration in my pom.xml:


After a “mvn clean install” the problem was gone. There is also a nice side-effect of this modification: before editing the maven build took about 2:30min on my developer-machine, now it’s done in 1:30min.

Rolf Engelhard


Comment (1) Write a comment

Leave a Reply

Required fields are marked *.