Maven2 Coverage, build hangs, fork=true?

Hi,

I am trying to configure TeamCity to use coverage with Maven2.  Without coverage enabled my tests run fine, but with coverage enabled the build hangs.  Last lines in the build log:

[11:53:17]: ---- IDEA coverage runner ----
[11:53:17]: sampling ...
[11:53:17]: include patterns:
[11:53:17]: nl\.blahblah\..*
[11:53:17]: exclude patterns:


According to the documentation I should enable fork=true.  I added


-Dmaven.junit.fork=true -Dmaven.junit.forkmode=once


to the "Additional Maven command line parameters:" field in my build runner configuration, is that what I am intended to do? Are there any specifics to configuring Maven, Surefire/JUnit, TeamCity  etc. when using coverage?


Kind regards,
Walter
9 comments

What version of Surefire plugin do you use?


0

Hi Pavel, using surfire 2.4.3.

Walter

0

Could you please take thread dump from the build process (see "view thread dump" link on the build results page) and attach it here?

0

What version of Java do you use? We have similar request: http://youtrack.jetbrains.net/issue/TW-11820 and it seems upgrade of the Java fixes the problem.

0

Using java version "1.6.0_17".

I suspect the problem is Glassfish related.   I just ran the same build with coverage enabled in the Tomcat bundled TeamCity, and it works just fine.  Even though it uses the exact same Java installation as Glassfish does.

I'll see if I can upgrade Java to 1.6.0_20.

kind regards,
Walter

0

It can't be server related because build is running on agent which itself does not have dependencies on application servers.

0

That's really odd...

Except for changing the teamcity server port, I left the agent completely unchanged. I just undeployed TeamCity from Glassfish, downloaded the Tomcat bundled edition to the same machine, and ran bin/teamcity-server.sh start.

Could it have something to do with communication between agent and teamcity? Differences in security policies in Tomcat and Glassfish?  Just a wild guess... One of the threads seems to block in

java.security.BasicPermission.newPermissionCollection(BasicPermission.java:257)

Walter

0

No, it completely independent from Tomcat or Glassfish, unless your build depends on them. If it stopped reproducing this is because deadlocks are not stable. In fact it is really hard to catch a deadlock reliably.

Permissions checking can play some role here, but I would try with newer Java first.

0

Please sign in to leave a comment.