Maven sure plugin forever forever

Question

My installation of the project was perfect until yesterday, but today my installation is stuck in the following,

Apache Maven 2.2.1 (r801777; 2009-08-06 20: 16: 01 + 0100)

Java Version: 1.6.0_20

[INFO] Surefire report directory: C:\Perforce\project-name\target\surefire-reports

Basically, after this line the installation is not performed at all. Any thoughts?

• I tried mvn -X and I get the same.
• I even upgraded version to version 2.6 and still get the same issue.
• I made sure that there are no debugging options, i.e., the JVM does not wait for any debugger to connect (-Xdebug options)

Answer 1

I passed forkMode = never, and now I noticed that one of the tests did not run at all. The reason was that he used ehcache and kept the entries in the directory "java.io.tmpdir", which was my temporary user directory.

From today, the system has also started slowly. Then I noticed that my C: / users /../ AppData / Local / Temp folder had about 2 million files, most of which were either p4ticket234234.txt or Visual Studio log files.

As soon as I cleaned up these log files, my build was successful. The jconsole console or some kind of date stream would more display the same way I think.

Answer 2

Dump the thread of the correct process using jstack and submit a question

Answer 3

Surefire waits for all non-daemon threads in your application to complete. Easy to miss one or the other. For example, be sure to call the shutdown method Executors if you use it. If you do the streaming processing yourself, you basically need to either make them daemon or make sure they complete. Flow dump can help detect lingering flows.

Answer 4

Use jps, jstack or jvisualvm tools from the JDK to get a list of processes and their thread dumps.

Answer 5

I had the same problem. Suddenly, my “mvn test” hung, it would seem, forever, and the associated org.apache.maven.surefire.booter.ForkedBooter process took 1.7 GB! After much research, it turned out that the problem was that I deleted the class that spring -core created as spring bean in the spring XML configuration. As soon as I removed the element corresponding to the remote class from the spring XML configuration, everything was fine. This seems like a mistake in spring and assured use when there is no reasonable warning or error.