[
http://jira.codehaus.org/browse/MCOBERTURA-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=264501#action_264501
]
Benson Margulies commented on MCOBERTURA-128:
---------------------------------------------
Preliminary investigation suggests that this can't be done.
Here's how this plugin works. The cobertura plugin is configured to run a
'parallel lifecycle' for 'test', with the output class directory redirected to
the cobertura instrumentation directory. There's no mechanism for pushing
parameter values from the configuration of the cobertura plugin to the
configuration of surefire.
I've got a question out to the maven list in case I missed something, but
failing that i'm going to close this as impossible.
> 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/[email protected]/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
