Monday, December 16, 2013

Guest post about Brackets and building Brackets Extensions

It’s already a couple of weeks ago, that I provided two guest posts about Brackets for Safari Books Online.
Please have a look at introduction to Brackets and Building a Brackets Extension and let me know what you think.
I’d like to hear your feedback. Thanks.

Friday, November 8, 2013

git re-merge done easy

I messed up some files during a larger merge a couple of days ago. When I tracked down the files that had issues (in my case the unit tests didn't succeed anymore), I wondered if there is an easy way to revert to the version of the file before the merge and redo the merge or at least bring back the file with the conflict markers.

I was looking for an elegant solution. Something must exist that helps engineers to easily resolve situations like this.
After 45 seconds of research (sometimes it's that quick if you know the right words to search for), this result on StackOverflow came up.
git checkout -m <filename>

Very nice solution. I was able to go back to the state, where the file contained all the conflict markers and I was able to resolve the issue pretty quickly.

Yes, sometimes git is really easy.

Sunday, March 3, 2013

Using cobertura with gradle

I wanted to get code coverage for my current groovy project. Since I use gradle and all of my source is written in groovy, I searched for a gradle plugin that provides cobertura functionality for groovy files. I found two (perhaps there are a more available)

Using both plugins wasn’t a big deal. There is a slight difference how to set them up in your build.gradle file though. Both plugins provide very similar configuration options to tweak cobertura’s behavior. Let’s take a look.

Using Eric Wendelin’s Cobertura plugin

Adding the plugin to the build.gradle

I’m using gradle 1.4 for this exercise and I added the following to my build.gradle:

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath "net.saliman:gradle-cobertura-plugin:1.1.0"
    }
}

apply plugin: 'cobertura

This will provide you with four new tasks:

  • coberturaInstrumentMain
  • coberturaInstrumentTest
  • testCoberturaReport
  • coberturaConfigureTest

So, which task to call to determine the code coverage? Simply run the test tasks and your source will be instrumented prior to executing your tests.

But what you really want, is to run the check tasks because this will not only run your tests on your previously instrumented source, but it will also create the coverage report. And that’s basically what we want.

The plugin provides some configuration options to tweak cobertura’s behavior

option description
format ’html’ (default) or ’xml’
reportsDir Path to report directory for coverage report. Defaults to ${project.reportsDir.path}/cobertura
includes List glob paths to be reported on. Defaults to [‘**/*.java', ‘**/*.groovy', ‘**/*.scala’]
excludes List glob paths to exclude from reporting. Defaults to [‘**/*Test.java', '**/*Test.groovy', '**/*Test.scala’]
ignores List regexes of classes to exclude from instrumentation. Defaults to [‘org.apache.tools.*', 'net.sourceforge.cobertura.*’]

To specify the output format of cobertura’s coverage report you have to do this:

cobertura {
    format = ‘xml’
}

Using Steve Saliman’s Cobertura plugin

This plugin is based on the work of gradle_cobertura. The original version had some issue with the latest gradle version, so I decided to pick one of the 20 forks. The one with the most recent changes was Steve Saliman’s Cobertura plugin. You can find the setup instructions in the README. Currently the compatibility chart shows that gradle 1.1 is the highest supported version right now. I’m using it with gradle 1.2, 1.3 and 1.4 and they work too. So, let’s move ahead and give it a try.

Adding the plugin to the build.gradle

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath "net.saliman:gradle-cobertura-plugin:1.1.1"
    }
}
apply plugin: 'cobertura'

This will add 2 new tasks:

  • cobertura
  • instrument

To get your coverage report you need to run the cobertura task and the report will be created.

There are a couple of options available to this plugin to change the cobertura behavior:

option description
coverageDirs Directories under the base directory containing classes to be instrumented. Defaults to ${project.sourceSets.main.classesDir.path}
coverageDatafile Path to data file to use for Cobertura. Defaults to ${project.buildDir.path}/cobertura/cobertura.ser
coverageReportDir Path to report directory for coverage report. Defaults to ${project.reportsDir.path}/cobertura
coverageFormats Formats of cobertura report. Default is a single report in ‘html’ format
coverageSourceDirs Directories of source files to use. Defaults to ${project.sourceSets.main.java.srcDirs]
coverageIncludes List of include patterns
coverageExcludes List of exclude patterns
coverageIgnores List of ignore patterns

Fix broken links in coverage report

In order to have a working link to the groovy source files in the coverage report, it’s necessary to add the following to your build.gradle. This will add the groovy source directory to the list of coverageSourceDirs

cobertura {
    coverageSourceDirs << project.sourceSets.main.groovy.srcDirs
}

Report location

For both plugins, the generated report can be found in build/reports/cobertura.

Summary

I have to admit, that both plugins are too similar in functionality to declare a clear favorite. In general, both plugins have subtle differences in regards of their configuration. I like that Eric Wendelin’s Cobertura plugin supports groovy (and scala) files right out of the box without further configuration. But this is only a very small advantage. I’ll stick with Steve Saliman’s Cobertura plugin for a while, since there is still active development. Not a strong reason, but as I mentioned earlier, there are only subtle differences between both plugins.

The choice is up to you.