[
http://jira.codehaus.org/browse/MCOBERTURA-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies reassigned MCOBERTURA-128:
-------------------------------------------
Assignee: Benson Margulies
> Unable to get lock on cobertura.ser.lock when build is running from a NFS
> mount
> -------------------------------------------------------------------------------
>
> Key: MCOBERTURA-128
> URL: http://jira.codehaus.org/browse/MCOBERTURA-128
> Project: Maven 2.x Cobertura Plugin
> Issue Type: Bug
> Affects Versions: 2.2, 2.4
> Environment: RHEL5 2.6.18-164.11.1.el5
> NFS Mounted NetApp
> Hudson 1.372
> Maven 2
> Reporter: Ryan Shelley
> Assignee: Benson Margulies
>
> When running a Maven build where the source files exist on an NFS mounted
> NetApp, Cobertura reports the following message (abridged path to lock file):
> ---------------------------------------
> Unable to get lock on .../cobertura.ser.lock: null
> This is known to happen on Linux kernel 2.6.20.
> Make sure cobertura.jar is in the root classpath of the jvm
> process running the instrumented code. If the instrumented code
> is running in a web server, this means cobertura.jar should be in
> the web server's lib directory.
> Don't put multiple copies of cobertura.jar in different WEB-INF/lib
> directories.
> Only one classloader should load cobertura. It should be the root
> classloader.
> ---------------------------------------
> After researching, I found a case where Cobertura is attempting to create a
> lock via NIO and failing due to the NFS mount. The work around is to apply
> the system property "cobertura.use.java.nio" and set it to "false". I
> attempted to set this property through the Cobertura Maven Plugin with:
> <plugin>
> <groupId>org.codehaus.mojo</groupId>
> <artifactId>cobertura-maven-plugin</artifactId>
> <version>2.4</version>
> <configuration>
> <systemProperties>
> <property>
> <name>cobertura.use.java.nio</name>
> <value>false</value>
> </property>
> </systemProperties>
> </configuration>
> </plugin>
> however the property did not get passed on to Cobetura. Instead, I added it
> to Surefire and it was passed in properly. This seems like something that I
> should be able to pass into the Cobertura Maven Plugin, however, and not
> through Surefire:
> <plugin>
> <artifactId>maven-surefire-plugin</artifactId>
> <configuration>
> <systemProperties>
> <property>
> <name>cobertura.use.java.nio</name>
> <value>false</value>
> </property>
> </systemProperties>
> </configuration>
> </plugin>
> The thread that I came across that helped identify this was:
> http://www.mail-archive.com/user@mojo.codehaus.org/msg01649.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
