I’d like to hear your feedback. Thanks.
random thoughts about computer tech, web technologies, javascript, nodejs, groovy, java, webdev, process automation, jenkins, eclipse, android and stuff that worked for me
Monday, December 16, 2013
Guest post about Brackets and building Brackets Extensions
I’d like to hear your feedback. Thanks.
Friday, November 8, 2013
git re-merge done easy
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>
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.
Monday, February 11, 2013
List all available instruments templates
For my current project I usually used the Automation.tracetemplate to launch my iOS app. But after I've upgraded Xcode from 4.3 to 4.5, the filesystem location of the instruments templates have been slightly changed. The framework that I wrote for the performance tracking system failed in finding the template. I started to investigate a better solution to be able to deal with different Xcode versions that could be found on the dev machines.
For that reason I created a little helper class to identify the version of Xcode to locate the correct path of the Automation.tracetemplate. That works pretty fine, but I don't know if this will work for future Xcode versions too. This solution required xcodebuild -version to determine the Xcode version and xcode-select -print-path to determine the location of the Xcode folder. I needed this information to assemble the path to the templates.
There must be a better, shorter way of getting this information.
A better solution
Running instruments -s and parsing the output will give me path to the Automation.template. without any guessing or probing. I hope this option will remain available in instruments in future versions.
Tuesday, January 29, 2013
Das tote Pferd
Und heute ist es wieder passiert. Ich hab die Zeichen wieder nicht gesehen. Vielleicht waren dort auch keine, aber das Pferd auf dem ich geritten bin ist definitv tot. Leider bin ich nicht aus freien Stücken abgestiegen, sondern abgestiegen worden.
Mit anderen Worten: mein Arbeitgeber hat heute mal wieder eine neue strategische Ausrichtung bekannt gegeben und leider war mein Team, und damit eine Menge anderer Kollegen, nicht mehr direkt Teil dieser neuen Strategie. Zum Glück wurde aber keiner meiner Kollegen entlassen. Das hat die Firma aus den vergangenen Umstrukturierungen gelernt. Erst fire, dann hire ist teuer.
Hab ich noch einen Job? Ja, hab ich. Also kein Grund zum meckern. Was für ein Job? Keine Ahnung.
Warum rege ich mich darüber auf? Du bist in den USA. Da ist das doch gang und gebe. Ja, das ist zwar richtig und es verwundert mich auch nicht wirklich. Es ist nur die Häufigkeit der Veränderungen in den letzten 2 Jahren gewesen. Und jedes mal das ungute Gefühl, dass ich irgendwann durch die Mühlen falle und keinen Job mehr habe, wir das Land verlassen müssen, weil das Visum an meinen Arbeitgeber gebunden ist.
Naja, jetzt heisst es erstmal abwarten und sehen was das kommt. Jeder Neuanfang ist auch eine Chance etwas Neues zu lernen.
Also, es ist mal wieder Zeit etwas Neues zu lernen.