Home » Java » Enterprise Java » Creating Sonarqube Projects

About Bear Giles

Creating Sonarqube Projects

Sonarqube (nee Sonar) is da bomb. It’s not something you have to check daily but if you’re serious about quality you’ll check it during sprint planning if not weekly.

Check out a sample project at nemo.sonarqube.com, e.g., OpenJPA, to get an idea of what information is available. You might want to focus on a specific component at first, e.g., OpenJPA JDBC.

As a developer I’m mostly interested in the “issues” (mostly FindBugs and Squid) and “unit test coverage.” As an architect I’m mostly interested in the “package tangle index” and “complexity” – the former is a measure of proper encapsulation and decoupling and the latter is a measure of maintainability.

It’s important to view these numbers with an appropriate amount of salt. They give valuable insights but it takes a bit of experience to make the best use of them. That’s why it’s important to keep this information away from the bean counters who will set unreasonable standards like 90% code coverage in all unit tests. (This can be impossible to achieve if you have rich exception handling but no way to mock the classes that will throw those exceptions. Only a fool would trade code robustness for a higher score.)

Installing Sonarqube

It’s straightforward to install sonarqube. It comes bundled with its own webapp server and embedded database so you can check it out by just unpacking it and running the startup script. A production system should use a real database. Multiple databases are supported.

Check the sonarqube site for details.

Creating Our Project

I’ll admit it – creating a project is very counter-intuitive. In a nutshell everything is handled by pushing data to the server without creating anything on the sonarqube server first. (You’ll still want to create admin users on the sonarqube server.)

In practice this means that we add a maven plugin. This is an expensive plugin so it’s common to use a custom profile, e.g., “sonar” (for the legacy name).

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

                                        <!-- implmentation is needed only for Maven 2 -->
                                        <rule implementation="org.jacoco.maven.RuleConfiguration">
                                                <!-- implmentation is needed only for Maven 2 -->
                                                <limit implementation="org.jacoco.report.check.Limit">

Updating Our Project

The sonar plugin is expensive so it should not be run as part of a routine build. A common practice is to schedule a nightly build on the CI server (Hudson, Continuum, etc.) Developers may also want to perform off-schedule builds while working on the issue backlog – it’s not uncommon for one fix to introduce other lower-priority issues.

Source Code

A sample project using this plugin is at https://github.com/beargiles/project-student [github] and http://beargiles.github.io/project-student/ [github pages].

This project illustrates the need to be intelligent about how we interpret the results. I use two common practices – throwing an internal exception instead of returning a null value and using a custom ‘UnitTestException’ to test failure code without cluttering the logs with extraneous information. The code looks the same as questionable code so it’s properly flagged but there doesn’t seem to be a way to silence squid warnings. (Findbugs has its own SuppressWarnings annotation.)

Overall it’s still a huge win.

(Update: it’s possible to control the squid warnings via the sonarqube ‘Quality Profiles’ tab. This can be used to reduce the severity level to ‘info’ but I’m hesitant to disable these tests outright since they are sometimes legitimate warnings. That’s why I strongly prefer to use per-instance FindBugs SuppressWarnings annotations instead of changing those warning levels.)

Reference: Creating Sonarqube Projects from our JCG partner Bear Giles at the Invariant Properties blog.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!


1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

6. Spring Interview Questions

7. Android UI Design


and many more ....



Leave a Reply

Your email address will not be published. Required fields are marked *


Want to take your Java Skills to the next level?
Grab our programming books for FREE!
  • Save time by leveraging our field-tested solutions to common problems.
  • The books cover a wide range of topics, from JPA and JUnit, to JMeter and Android.
  • Each book comes as a standalone guide (with source code provided), so that you use it as reference.
Last Step ...

Where should we send the free eBooks?

Good Work!
To download the books, please verify your email address by following the instructions found on the email we just sent you.