[ 
https://jira.codehaus.org/browse/MCOBERTURA-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mirko Friedenhagen updated MCOBERTURA-128:
------------------------------------------

    Priority: Minor  (was: Major)
      Labels: documentation  (was: )

Hello,

I have reclassified this as a minor bug for two and a half reasons:
* There is sound workaround in the description of the bug.
* IMO this property may probably be passed to the surefire-plugin only anyway.
* NFS is evil anyway (just joking ;-))

I would suggest to just enhance the FAQ page with a description how to 
circumvent problems with NFS.

Best Regards
Mirko


                
> Unable to get lock on cobertura.ser.lock when build is running from a NFS 
> mount
> -------------------------------------------------------------------------------
>
>                 Key: MCOBERTURA-128
>                 URL: https://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
>            Priority: Minor
>              Labels: documentation
>
> 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, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.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


Reply via email to