Deliver code coverage indices for Scala using Gradle and SCCT

This post is a kind of follow up post to Gradle rocking Scala Specs2 tests. After setting up the build supporting Specs2 tests we could take it a step further to provide information about the code coverage of the tests.

SCCT is a code coverage tool for Scala. One benefit of SCCT is that the output format is compliant, to the widely known Cobertura so it could easily integrated into Jenkins for example. „Deliver code coverage indices for Scala using Gradle and SCCT“ weiterlesen

Gradle rocking scala specs2 tests

In preparation of the upcoming Coursera course „Reactive Programming“ I just want to refresh my Scala skills by porting the Coursera Downloader from Python to Scala.

Setting up the initial build with Gradle is quite easy using the Scala Plugin. Looking around for some testing framework I have chosen Specs2 . Running Gradle after building some simple unit tests shows up that the tests are not executed at all. The build passes without running one single tests. Even declaring the tests to be processed by a JUnit4 runner did not want show up a single tests result. So I came up with the following simple solution. I add a new specs2 task to my Gradle build using the specs2 file runner:

 * Run Spec2 tests
task specs(type: JavaExec, dependsOn: testClasses) {
    main = 'org.specs2.files'
    args = ['console']
    classpath sourceSets.main.runtimeClasspath
    classpath sourceSets.test.runtimeClasspath
    classpath configurations.testRuntime
    classpath configurations.runtime

The file runner will select all files matching .*Spec in the test source directory which default (src/test/scala) nicely conforms the default project setup. If necessary it could be adjusted by setting the specs2.srcTestDir system property. For more information on the Specs2 Runners refer to the Specs2 documentation.

Now you have only to hook in the test step execution which could be easily achieved by extending the test task to depend on the specs2 tasks as well:

 * and  add them to the default test set
test.dependsOn specs

Running the test target of the Gradle build once again shows up the execution of the specs2 target and all tests and specifications.


Marino Borra points out that he could run the specs tests successfully with the default gradle test task by simply adding the @RunWith(classOf[JUnitRunner]) annotation.

Krama, Jenkins and Bitbucket colluding continuous integration

Having an automatic build process, high grade unit and integration tests and a CI (continuous integration) system helps to enforce a certain level of quality. Runtraction is a Javascript HTML5 based mobile (web) application. It was scaffolded using Yeoman utilizing:

  • Yo for scaffolding the intial project structure and additional components,
  • Grunt for build automation and
  • Bowers dependency management.

The Yo utility creates Karma tests suites beside the source and various other artifacts. Karma integrates well with several CI products like Jenkins CI and Travis CI. Travis CI provides a free continuous integration service and pthe integration into an own project is just a matter of adding an appropriate .travis.yml configuration file.

The Runtraction source code lives at Bitbucket.

So everything seems to be fine – but unfortunately Travis CI is very tightened to Github so it is not possible to use it from Bitbucket directly. Furthermore there is no service trigger for Tavis CI in Bitbucket too. „Krama, Jenkins and Bitbucket colluding continuous integration“ weiterlesen

DIY: Replace Google Reader by Tiny Tiny RSS

After Google announcing the end of service date for Google Reader the question arises where to move next. Once again back to Bloglines – that is the service which was said to be dead, but ironically it survived Google Reader or choose one of the numerous other alternatives (eq. Feedly or GoodNoows) which are worth to take a look at them. But you might running in the same trap again – they could be closed for whatever reasons. So I searched for an open source and shared-hosting friendly replacement and I will give Tiny Tiny RSS a try.

The setup procedure is quite easy, download the distribution,  unpack it and follow the installation instructions. Afterwards you should be able to login to you Tiny Tiny RSS installation but there where some strange errors I got rid of by using the latest index.php file from the github repository and upgrading the php version to 5.4 .

Quick tip: Bypass the version check at Oracle Service Bus project import

Using different versions of the Oracle Service Bus (OSB) runtime and the Oracle Enterprise Pack for Eclipse (OEPE) might result in annoying error saying that the version of the import artifact is not compatible to servers version. This could (but probably should not) quick fixed by changing the ExportInfo file inside the created jar archive. Look for the following line and change the value to your desired version:

<imp:properties xmlns:imp="">
  <imp:property name="productversion" value=""/>

Afterwards it should be possible to import the artifact successfully.

Pure XSL localization

Transforming XML data to a human readable presentation of content could be easily done using XSL stylesheet transformations. Even various task could be performed by a standard XSL processor without demanding additional programming language integration. The following example sets up a project structure, needed resource files and transformations to localise the output of an XML transformation by purely using XSLT and XPath.
„Pure XSL localization“ weiterlesen

IMHO: Lessons learned from WhatsApp

Building an open alternative to the propriety WhatsApp messenger would be a desirable option. And indeed there are lots of open (e.g. beem, yaxim,…) as well as non-free competitors but none of those could supersede it, although there were some reports about security problems and account hijacking. So what might be a key feature to bring the open alternatives to a broader audience?
„IMHO: Lessons learned from WhatsApp“ weiterlesen