First8 staat voor vakmanschap. Al onze collega’s zijn een groot aanhanger van Open Source en in het bijzonder het Java-platform. Wij zijn gespecialiseerd in het pragmatisch ontwikkelen van bedrijfskritische Java toepassingen waarbij integratie van systemen, hoge eisen aan beveiliging en veel transacties een belangrijke rol spelen. Op deze pagina vind je onze blogs.

3 Steps For Analyzing a Gradle Project With SonarQube Using Docker

How hard can it be to get up and running with a Gradle project and getting it analyzed with SonarQube locally?

The ingredients are:

SonarQube (formerly Sonar) is an open source platform for continuous inspection of code quality.


Gradle is an open source build automation system.


Docker allows you to package an application with all of its dependencies into a standardized unit for software development.


“How easy is this?” was a question I had after I decided to reformat my company HP EliteBook with Windows into a full Linux Mint machine.

So, I’ve already played around with Docker and IMHO this works much more pleasant under Linux, so I thought it’s time to play around with it some more and may be get a project analyzed by SonarQube without too much hassle.

So, how easy is this?

Step 1 – Getting SonarQube with Docker

First thing I went to look for was a Docker image which already has SonarQube in it. This is the future IMHO: running whatever components you need inside a container.

At least for development and testing purposes this is a great win: no matter the underlying OS or personal work environment, the image is what it is, and as long as you can run Docker you’ll know “exactly” what will be running.

No time to create an image for now, just get one someone already shared in one’s own company or on DockerHub.

Docker Hub is the canonical platform for publishing and consuming Docker container images.

Just searched for “sonar”.


243 reposiories at the moment. There were 2 which caught my attention:

  • sonarqube – which is official. Has 165 stars and 243 thousand pulls.
  • orangesignal/sonar which has 2 stars and 378 pulls
  • tpires/sonar-server which has 18 stars and 94 thousand pulls.

Although numbers #1 and #3 seem to have a higher stars/pulls combination, I went for orangesignal/sonar because it used Docker Compose.

Docker Compose

On orangesignal/sonar’s DockerHub page a GitHub repo is referenced. Cloned it:

The directory layout is:

Various versions of SonarQube (actually Dockerfiles ofcourse) and an interesting docker-compose.yml which contains the “composition”.


Instead of H2 or MySQL this says to use a Postgres database, using the Docker image postgres:9 and run it under a certain host name and port. It is followed by the part where the latest published version of the orangesignal/sonar image is referred to and linked with the Postgres database.

I had Docker already installed, but I yet had to install Docker Compose to be able to run

This starts the whole shebang.

Accessing the SonarQube Dashboard

On http://localhost:9000 now SonarQube is serving:


No projects analyzed yet.

Step 2 – Getting Example Gradle Project

I needed an example Gradle project.

I could have chosen to create a clean, Java-based Gradle project from scratch, but adding some sources and tests to analyze would make me go over the 5 minute time-limit I set for myself.

Best option is to just use a project from SonarQube’s own examples GitHub repository:

The directory /projects contains sample projects for:

  • the different analyzers (SonarQube Runner, Maven, Ant)
  • the different languages (Java, Cobol, .Net, etc.)
  • the different ways to execute unit tests and get code coverage data

Examples use the Sonar Runner, which is a deprecated plugin now. Luckily, the java-gradle-simple project was exactly what I needed.

Output of tree (another beautiful Linux tool):

Some stuff I hoped SonarQube could report something about. What I was looking for was an example of a proper build.gradle using the Sonar Gradle plugin.


As you can see there are a few plugins:

Besides the Java plugin, there’s also the SonarQube plugin and JaCoCo plugin. The latter provides Java code coverage metrics using the JaCoCo (“Java Code Coverage”) library, created by the EclEmma team.

Furthermore there some other stuff configured, such as Sonar properties:

Part is for identification the project inside SonarQube, for if you’re using it for multiple projects.

I left everything as-is because I can just start…

Step 3 – Analyzing Using Gradle Sonar Plugin

The Gradle Sonar plugin uses all kinds of defaults and uses much of the information from the Gradle build to analyze a project.

So I hoped Things Just Worked (which is kind of a pitfall if everyhing goes smooth as of far – with minimal configuration) so just see what happens if we do:

With actually default SonarQube settings this would have worked and a local H2 database would have been found.

Where is SonarQube actually?

Unfortunately, our docker-compose.yml says otherwise – we’re using a Postgres database instead with a different JDBC settings – not an H2 database on jdbc:h2:tcp://localhost/sonar.

We can either put override the defaults by setting some global properties in ~/.gradle/ like

Or pass it on the command-line (keeping the defaults):

SonarQube starts and finishes analyzing this small project quickly:

The result:


The Dashboard of SonarQube now lists our Simple Java Project. The overview of the project now reveals much information about the state of the current code base.


SonarQube’s own example project has 2 (deliberate) issues:


Issues overview says what’s really going on:




So tho answer my original question: it isn’t that hard to have a Gradle project analyzed by a locally running SonarQube installation.

Since I already had Docker and Docker Compose installed it took “5 minutes” for us to get here, but it will take you 10 more minutes to squash the technical debt.

Now, what are you waiting for – go fix it! 🙂

Further Reading