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
Comment actions Permalink

What version of Surefire plugin do you use?


0
Comment actions Permalink

Hi Pavel, using surfire 2.4.3.

Walter

0
Comment actions Permalink

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
Comment actions Permalink

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
Comment actions Permalink

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
Comment actions Permalink

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

0
Comment actions Permalink

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
Comment actions Permalink

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.