CodeCoverage Plugin

Plugin reports 0% coverage in plugin

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Duplicate
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None

Description

I've discovered an issue with the latest code coverage plugin. This worked fine with the older grails 1.0.3 and .9 version of the coverage plugin.

Attached is a grails plugin that uses your plugin to generate coverage numbers. You'll notice that it reports 0% coverage which is incorrect. What I discovered is that if you use the code coverage plugin in a plugin and some of the code you are testing is included in the doWithSpring closure, you get 0 coverage numbers.

If you run test-app on the attached plugin you'll see 0%.

Then comment out the following from the CoverageBugGrailsPlugin.groovy

def doWithSpring = {
pResolver(com.travelocity.grails.plugins.configuration.io.ResourcePathResolver) { pathPrefix = "/var" }
}

Do a grails clean and grails test-app again and you'll get coverage.

Thanks for your time,

Tony Perkins

Attachments

  1. File
    _Events.groovy
    26/Aug/10 4:35 AM
    6 kB
    Markus Ketterer
  2. GZip Archive
    coveragebug.tar.gz
    14/May/09 11:46 AM
    224 kB
    Mike Hugo
  3. File
    InstrumentCode.groovy
    26/Aug/10 4:35 AM
    4 kB
    Markus Ketterer

Issue Links

This issue duplicates:
GPCODECOVERAGE-18 coverage not applied to classes in plugin.groovy Major Open

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Alberto Barcelos added a comment -

I have the following plugins installed in my grails app (1.1.1)

plugins.mail=0.7.1
plugins.acegi=0.5.2
plugins.flex=0.2
plugins.crypto=2.0
plugins.code-coverage=1.1.7
plugins.hibernate=1.1.1

And I'm getting the same problem with my tests. So this is issue is not affecting only plugin projects but projects that use plugins that use the doWithSpring closure

Show
Alberto Barcelos added a comment - I have the following plugins installed in my grails app (1.1.1) plugins.mail=0.7.1 plugins.acegi=0.5.2 plugins.flex=0.2 plugins.crypto=2.0 plugins.code-coverage=1.1.7 plugins.hibernate=1.1.1 And I'm getting the same problem with my tests. So this is issue is not affecting only plugin projects but projects that use plugins that use the doWithSpring closure
Hide
Permalink
Mike Hugo added a comment -

Alberto - can you create a small project that illustrates the problem? I can replicate it with Tony's example, but with a regular grails app using plugins I am still getting coverage for classes in the main app

Show
Mike Hugo added a comment - Alberto - can you create a small project that illustrates the problem? I can replicate it with Tony's example, but with a regular grails app using plugins I am still getting coverage for classes in the main app
Hide
Permalink
Raffael Marcovacky added a comment -

the same here for grails 1.1 with cobertura-plugin 1.1.7 while 0.9 with 1.0.3 works fine.

plugins.audit-logging=0.5
plugins.flex=0.2
plugins.hibernate=1.1
plugins.code-coverage=1.1.7

...
[cobertura-instrument] Cobertura 1.9.3 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file
[cobertura-instrument] Instrumenting 859 files
[cobertura-instrument] Cobertura: Saved information on 0 classes.
[cobertura-instrument] Instrument time: 312ms
...

Show
Raffael Marcovacky added a comment - the same here for grails 1.1 with cobertura-plugin 1.1.7 while 0.9 with 1.0.3 works fine. plugins.audit-logging=0.5 plugins.flex=0.2 plugins.hibernate=1.1 plugins.code-coverage=1.1.7 ... [cobertura-instrument] Cobertura 1.9.3 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file [cobertura-instrument] Instrumenting 859 files [cobertura-instrument] Cobertura: Saved information on 0 classes. [cobertura-instrument] Instrument time: 312ms ...
Hide
Permalink
Jan Rudert added a comment -

I experienced the same problem. In my case the solution was to remove older asm*.jar files from my project dependencies and ensuring that there are only the asm-jars of the version that comes with the cobertura plugin

Show
Jan Rudert added a comment - I experienced the same problem. In my case the solution was to remove older asm*.jar files from my project dependencies and ensuring that there are only the asm-jars of the version that comes with the cobertura plugin
Hide
Permalink
Alberto Barcelos added a comment -

Many thanks Jan! That worked perfectly. I've done exactly what you said and it works fine now.

Unfortunately I was not able to reproduce that problem in a new 1.1.1 project like Mike Hugo asked. We get to the point of doing it mannualy without the plugin just to see the same problem in the end.

Thanks

Show
Alberto Barcelos added a comment - Many thanks Jan! That worked perfectly. I've done exactly what you said and it works fine now. Unfortunately I was not able to reproduce that problem in a new 1.1.1 project like Mike Hugo asked. We get to the point of doing it mannualy without the plugin just to see the same problem in the end. Thanks
Hide
Permalink
Tony Perkins added a comment -

The "remove older asm*.jar files" solution didn't work for me. It appears that I only have the asm jar files that came with the plugin.

Show
Tony Perkins added a comment - The "remove older asm*.jar files" solution didn't work for me. It appears that I only have the asm jar files that came with the plugin.
Hide
Permalink
Alberto Barcelos added a comment -

To put it clearly the problem I was facing wasn't the same issue Tony is facing.

I thought that maybe the two problems were somehow related but that's not true after all. So the "remove older asm*.jar files" solution doesn't solve the original issue like Tony stated.

Show
Alberto Barcelos added a comment - To put it clearly the problem I was facing wasn't the same issue Tony is facing. I thought that maybe the two problems were somehow related but that's not true after all. So the "remove older asm*.jar files" solution doesn't solve the original issue like Tony stated.
Hide
Permalink
Raffael Marcovacky added a comment -

Thanks Jan,

worked for me, either.

it is just quite odd that I had to remove asm-1.5.3.jar and to keep asm-attrs-1.5.3.jar to get it working.

Show
Raffael Marcovacky added a comment - Thanks Jan, worked for me, either. it is just quite odd that I had to remove asm-1.5.3.jar and to keep asm-attrs-1.5.3.jar to get it working.
Hide
Permalink
Jan Rudert added a comment -

To explain the problem with the older jars: By debugging I found out that there was a NoSuchMethodException concerning asm-code during instrumentation (caught in net.sourceforge.cobertura.instrument.Main, line 362 but not handled).

To debug I fetched the cobertura sources and changed ./plugins/code-coverage-1.1.7/scripts/_Events.groovy and added a debug port. Maybe that helps to find out pending issues.

def instrumentClasses() {
    try {
        ant.'cobertura-instrument'(datafile: "${dataFile}", forkedJVMDebugPort:5006) {
        ...
}
Show
Jan Rudert added a comment - To explain the problem with the older jars: By debugging I found out that there was a NoSuchMethodException concerning asm-code during instrumentation (caught in net.sourceforge.cobertura.instrument.Main, line 362 but not handled). To debug I fetched the cobertura sources and changed ./plugins/code-coverage-1.1.7/scripts/_Events.groovy and added a debug port. Maybe that helps to find out pending issues. 
def instrumentClasses() {
    try {
        ant.'cobertura-instrument'(datafile: "${dataFile}", forkedJVMDebugPort:5006) {
        ...
}
Hide
Permalink
Jan Rudert added a comment -

The problem is that cobertura's instrument task implementation fetches the classpath for the command line call from the grails-root-classloader and not the ant-classloader which in my opinion would only include the classes defined in "cobertura.classpath". I had to dig into this because I need the older asm-jars in my project. The new ones are only needed for the cobertura instrumentation stuff. I do not know how to bring this two requirements together...

Show
Jan Rudert added a comment - The problem is that cobertura's instrument task implementation fetches the classpath for the command line call from the grails-root-classloader and not the ant-classloader which in my opinion would only include the classes defined in "cobertura.classpath". I had to dig into this because I need the older asm-jars in my project. The new ones are only needed for the cobertura instrumentation stuff. I do not know how to bring this two requirements together...
Hide
Permalink
Markus Ketterer added a comment -

Hi Jan,

to bring the two requirements (old asm.jar for the app and new asm.jar for cobertura) together we did the following workaround.

We mavennized our grails app to manage the dependencies and splitted up the code-coverage plugin to have the instrumentation as its own grails exec command.

So, what you have to do is the following.

1. Mavennize your grails app
2. Add a profile 'instrument' to your pom. In this profile set the dependency to asm 3.0.

<profiles>
    <profile>
      <id>instrument</id>
      <dependencies>
        <dependency>
          <groupId>asm</groupId>
          <artifactId>asm</artifactId>
          <version>3.0</version>
        </dependency>
        <dependency>
          <groupId>asm</groupId>
          <artifactId>asm-tree</artifactId>
          <version>3.0</version>
        </dependency>
      </dependencies>
    </profile>
</profiles>

3. Install the grails-code-coverage 1.1.8 plugin
4. Put the attached scripts (_Event.groovy and InstrumentCode.groovy) into the script directory of the code coverage plugin.

Now you should be able to do the code coverage measurement:
1. Call mvn clean compile. This compiles your grails app using the old asm
2. Call mvn -P instrumtent -Dcommand=instrument-code grails:exec. This instruments the compiled classes using asm 3.0.
4. Call mvn test. This executes the tests and generates the code coverage reports.

Hope this helps.

Regards,
Markus

Show
Markus Ketterer added a comment - Hi Jan, to bring the two requirements (old asm.jar for the app and new asm.jar for cobertura) together we did the following workaround. We mavennized our grails app to manage the dependencies and splitted up the code-coverage plugin to have the instrumentation as its own grails exec command. So, what you have to do is the following. 1. Mavennize your grails app 2. Add a profile 'instrument' to your pom. In this profile set the dependency to asm 3.0. 
<profiles>
    <profile>
      <id>instrument</id>
      <dependencies>
        <dependency>
          <groupId>asm</groupId>
          <artifactId>asm</artifactId>
          <version>3.0</version>
        </dependency>
        <dependency>
          <groupId>asm</groupId>
          <artifactId>asm-tree</artifactId>
          <version>3.0</version>
        </dependency>
      </dependencies>
    </profile>
</profiles>
3. Install the grails-code-coverage 1.1.8 plugin 4. Put the attached scripts (_Event.groovy and InstrumentCode.groovy) into the script directory of the code coverage plugin. Now you should be able to do the code coverage measurement: 1. Call mvn clean compile. This compiles your grails app using the old asm 2. Call mvn -P instrumtent -Dcommand=instrument-code grails:exec. This instruments the compiled classes using asm 3.0. 4. Call mvn test. This executes the tests and generates the code coverage reports. Hope this helps. Regards, Markus
Hide
Permalink
Mike Hugo added a comment -

dupe of GRAILSPLUGINS-2417
GRAILSPLUGINS-2417 is not resolved yet, I'm just consolidating tickets

Show
Mike Hugo added a comment - dupe of GRAILSPLUGINS-2417 GRAILSPLUGINS-2417 is not resolved yet, I'm just consolidating tickets

People

Vote (3)
Watch (4)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.1#660-r161644) | Report a problem
Powered by a free Atlassian JIRA open source license for Grails project. Try JIRA - bug tracking software for your team.