Initial cobertura plugin classes.

This is a first pass at cobertura reporting. There are a few issues sill up for discussion.

• Cobertura can instrument Groovy classes w/mapping back to the source, and can also instrument Scala code. This implies that this task doesn't belong attached just to the Java plugin, as one might want to execute Cobertura instrumentation on projects that don't contain any java code.

• To be useful, Cobertura instrumentation needs to be run as part of the testCompile tasks, so that when the tests are executed instrumentation is generated. At the moment, I've left this as something that has to be defined in the build script:

test {
        dependsOn 'cbInstrument'
}

cbInstrument {
        dependsOn 'testCompile'
        outputDir = "build/classes"
}

• This plugin has to execute Cobertura from the command line, spawning a new JVM. This is because Cobertura is GPL licensed.

• This plugin is not totally feature complete, but the missing features are relatively trivial to add.

Hi Phil, I'm trying to add the TestNG support (http://jira.codehaus.org/browse/GRADLE-27) and I've separated out the things that need to be done to initialize the selected test-framework that is needs to be used during testing in a TestPolicy class depending on what is configured as the default or what is in the build script:

 
test { 
    useTestNG() 
}

or

 
test {
    useJunit() 
}

I don't know what your thoughts are about the TestPolicy class but if you like it maybe you can add a CodeCoveragePolicy. The CodeCoveragePolicy would be more complex as it would add task dependencies and not just initialize the Test class with the correct Ant task and options but I think it would be rather nice to be able to do:

test {
    useCobertura() 
}

or nothing and use a configurable default code coverage framework.

Hope you don't find me to forward and like the idea.

Hi Tom - interesting comments!

You made me think of common use cases for both situations. If you're writing unit tests, it's pretty unusual to have more than one test framework in use. Same for code coverage - I'm unlikely to be using Clover, Emma and Covertura at the same time...

So, running with your Policy idea - when one "includes" a test/coverage/whatever plugin into a project, it should manipulate/replace the relevant Policy and configure itself. "Policy" classes sound somewhat like Conventions... hm.

It's quite important the we decide on good defaults as well. At the moment, I'm using the cobertura plugin to generate reports when a build is performed by CI. I dont "care" about generating reports when I'm writing / improving unit tests, until I decide to check to see how I'm doing... so by default I want code coverage instrumentation to be invoked only when explicity asked for.

Phil, 'Policy' and 'Convention' are indeed very similar and I think we should go with Convention as it is already in the API (just getting to know the existing code base).

Looking at your comments about when coverage and reporting is desired I think we should also introduce a Convention that covers the environment the build is run in. So users can configure the environment convention on their development workstation differently from the ci-server environment. This would also handle http://jira.codehaus.org/browse/GRADLE-182 by enabling/disabling reporting as desired by the environment convention.

I see the following configuration flow for a build script containing:

usePlugin('java') or usePlugin('groovy')
test {
    useCobertura()
    useTestNG()
}

CodeCoverageConvention => CoberturaConvention (initializes codeCoverageOptions with CoberturaOptions - doesn't initializes code coverage ant task yet)
TestConvention => TestNGConvention (initializes the testOptions with TestNGOptions - doesn't initializes the test ant task yet).

Plugin calls javaConfigure or groovyConfigure on the Test task depending on the plugin being used. This triggers more environment specific configuration.
If test reporting is required the following tasks gets added:

• testReport task: generates the test report. This is currently included in the Test task but I think this is best put into a separate task.

If code coverage is required the test options need augmenting with coverage framework specific environment variables or more + some tasks get added:

• coverageInit task: instrumentation happens here, depending on the way the code coverage tool handles this step the classpath gets edited (e.g.: Emma has a couple of different options for instrumentation). This task is added before the test task and after the testCompile task.
• coverageMerge task: merge some of the coverage data files
• coverageReport task: generates the coverage report.
• coverageCheck task: validates the level of code coverage.
  (depending on the coverage framework used one or more of these tasks may not be supported).

Maybe split up tasks.testing package into sub packages codecoverage, execution and reporting, TestConventions and CodeCoverageConventions can stay in tasks.testing because they span more than one aspect of testing, not sure where to put the test/coverage-framework specifics add a single package for each test/coverage-framework under testing or one under each of the aspects or just put the specific framework classes under the test aspect package.

anyway I dumped more than enough of my brain activity for one comment to hold, comments welcome

Prompted by Luk Morbee's email of Wed 2009-03-25, I have become interested in making this Cobertura plugin usabel in one of my projects.

For the TestNG development a Git repository was used to support development. Personally I would prefer using Bazaar and Launchpad, but if Git is the tool that moves this forward then let's use that.

I have made a Bazaar branch of Luk's version as noted on his email, and I have a Gradle build for it so that I can use it.

Perhaps account should be taken of Emma as well?

What is the next stage?

Where are we with this, Russel?

Currently in a bit of a mess.

Luk is sticking with Grails 0.5 for now, is happy with the code he has, and so has backed out of progressing the project.

I have not found time to progress the project by moving the codebase to use Grails 0.8 (or any in between versions), and the changes of Gradle API are very significant I think.

There is also clearly interaction between this issue, GRADLE-26, GRADLE-554 and GRADLE-555. There was some mention on the mailing list of integrating Cobertura and Emma support with the CodeNarc and Checkstyle support, but that isn't happening as yet as far as I know.

The code is currently in a Bazaar branch on Launchpad, i.e. at lp:~russel/gradle/gradleCoberturaPlugin. I am not sure it is entirely useful though due to not being Gradle 0.8 enough.

Hm, that's a pain. I've just been through the somewhat annoying process of upgrading 80 odd projects and porting half a dozen plugins from 0.5 to 0.8 so I can understand why Luk is happy to stick to 0.5

I'll have a look at your branch and see what sort of effort is require to make it work and integrated with the CodeNarc/Checkstyle reporting...