That’s now a few weeks since I joined the JBoss Tools and JBoss Developer Studio team and started working on build. JBoss Tools is a HUGE amount of code, with about 35 components (or modules in Maven terminology) that are aggregated in a way that can be compared to the Eclipse release train, and that all use a “Common Build Infrastructure” based on Maven/Tycho to perform build and Jenkins to trigger it.
There are a lot of improvements in the pipe for Nick and myself to make build more and more agile, and to make it produce more and more interesting results. I feel very interested in going a step ahead of continuous integration, and open the road towards continuous improvement, automating QA to get reports about static analysis and code coverage on each build. I bet it will help developers to avoid mistakes and improve there code. (Advertising: You can learn more on this topic during next EclipseCon ).
Here are some of these topics that are worth this blog post:
QA with Sonar
About static analysis, my choice fully goes to Sonar, a webapp that provides a dashboard aggregating reports from several QA “services” (Findbugs, Checkstyle, Test reports, coverage…). Sonar provides nice integration with Maven and Jenkins & Hudson, and getting the whole working together is about a few minutes of configuration. The return on investment when setting up Sonar is very high and immediate. In my humble opinion Sonar is a must-have nowadays.
So, there are 2 bugs I encourage you to look at/vote for, in order to leverage Sonar, QA and continuous improvements in your favourite projects:
- @Eclipse.org : Set up a Sonar instance of Eclipse projects
- @JBoss.org: Set up Sonar for JBoss Tools (and more JBoss stuff?)
Jacoco, without Sonar
Jacoco is a very easy-to-set-up code coverage tool, with a very convenient Maven integration. With Jacoco, there is no need for instrumentation step to get coverage results, all is about giving a -java.agent=jacocoagent.jar property to your JVM. While using it, I did not detect any effect on performances. That’s pretty cool.
The current issue for Jacoco adoption is the reporting. Here are the known ways to analyse reports from a Jacoco coverage output file (aka jacoco.exec):
- Use the Jacoco Ant task to generate HTML reports
- Use the Jacoco maven:site integration to generate reports as part of maven:site
- Une EclEmma plugin to analyse Jacoco reports in your IDE
- Use Sonar
As a fan of Sonar, I think the Sonar-based approach is the best one. But both previous bugs show something clear: despite of my full enthusiasm for Sonar, community-wide infrastructures such as Eclipse.org or JBoss.org cannot set up a Sonar instance immediately. I guess this is because of issues with credentials, or hardware, or IT stuff. So we need to be able to consume Jacoco reports without Sonar.
The issues with all these approaches is that it introduces the need for a new build step or a new developer tool to analyze reports. The main dashboard for JBoss.org builds in Jenkins (and Hudson for Eclipse.org), then the ideal place for such reports would be a Jenkins plugin for Jacoco. Unfortunately this does not existt (yet), but a Jenkins issue is open for this. Now that I have lost some optimism in getting Sonar available for Eclipse.org or JBoss.org community quickly (as an impatient guy, quickly means today), this Jacoco Jenkins is now my #1 wish in the whole Java software world. Although setting up Jacoco for execution is very easy, setting up integrated reporting is still almost a blocking point for adoption.
So please, vote for this bug!!! iJacoco Jenkins plugin
Some other stuff
Since I’m writing here a wish list, I’d also like to share with you thib Jenkins issue I opened: Add an option to select Build status when no Test is found. The idea is simple: Even if no-one should never do that, it happens that we need to run a Jenkins build with skipped tests. Ok, it’s bad, but it happens. In such case, the fileset for Test results in Jenkins JUnit plugin does not match any existing report, and then build turn to FAILED/Red. When you have cascading of jubs, this is pretty annoying, since you’d rather see this build UNSTABLE/Yellow -my favourite- or SUCCESS/Blue. So this issue simply requests the ability to change the result of plugin when no test is found.
If you find this useful, you can vote for it.
Some Eclipse stuff 