gradle-cobertura-plugin

gradle-cobertura-plugin copied to clipboard

It does something weird and I don't know how to troubleshoot it. It basically causes 100% of my unit tests to fail.

Here's the failing output. https://travis-ci.org/samrocketman/jervis/builds/64361726

Here's my passing build after reverting the commit. https://travis-ci.org/samrocketman/jervis/builds/64497789

Here's the only change that breaks the build. https://github.com/samrocketman/jervis/commit/2eb4dbaaf9a1b0e226a06bc5f6c92cd7cf402da3

My project is built against all latest available major releases of Groovy between 1.8.9 and 2.4.3. The build fails on all versions of Groovy built.

2.2.8 also breaks for me. 2.2.5 works. 2.2.7 broken.

Unable to instrument file /home/shevek/java/gradle-stdproject-plugin/build/instrumented_classes/org/anarres/gradle/plugin/stdproject/StdProjectPlugin$1$1.class
java.lang.NoClassDefFoundError: org/gradle/util/Configurable
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:424)

2.2.6 works. 2.2.7 broken. 2.2.8 broken.

Using plugin 2.2.6 with coberturaVersion = '2.1.1' breaks

It would seem that there is something about cobertura 2.1.1 that is causing issues, but I can't think of what it might be. The fact that it has a problem with a gradle class is puzzling, since the gradle classes shouldn't be a factor to project code.

I'll try to look at this over the weekend.

I just tried to run the Jervis build with version 2.2.8 of the plugin. It fails if it uses Cobertura 2.1.1, but it succeeds if I change the Cobertura version to 2.0.3 (still using 2.2.8 of the plugin). I think this points to Cobertura itself as the source of the problem. I ran gradle dependencies under both configurations to see what classpath differences there are, and the one that jumps out to me is asm. Cobertura 2.0.3 used version 4, but Cobertura 2.1.1 uses version 5.

You could try to exclude the asm dependency of cobertura itself and run with asm 4.1, but I think this issue should be reported in the cobertura project itself.

Okay, thanks for validating @stevesaliman! I'll report it to Cobertura directly and link this issue. I'd recommend keeping this issue open for users who may create a duplicate issue. At least until Cobertura addresses the issue.