Sonar Maven plugin finds more bugs than Sonar Jenkins or Sonar CLI Scanner on multi-module Maven project

Question

Given the same code and the same SonarQube server with the same rules I get vastly different number of bugs and vulnerabilities found when scanning with mvn sonar:sonar vs the sonar-scanner CLI and a sonar-project.properties file or the Sonar Jenkins plugin. Like, more than twice as many.

I have the modules setup in the properties file and on the server I can see the count of lines of code is the same between the two scanners. I can see tests in one report but not the other but the tests aren't being counted for the lines of code or any bugs. An example of something Maven is finding that Jenkins is not is squid:S2160 where the parent class is part of the same module as the child class.

My main concern is whether the additional errors Maven is finding are legit, especially given that Sonar has deprecated the "SonarQube analysis with Maven" post-build action and the recommended Jenkins scanner ISN'T finding the same problems when looking at the same code. Which scanner is right, and if it's Maven is it still OK to use the deprecated step in Jenkins?

I've anonymized the properties file with the modules, but it looks like this:

# Required metadata
sonar.projectKey=groupId:artifactID
sonar.projectName=My Project name
sonar.projectVersion=0.0.4-SNAPSHOT

# Comma-separated paths to directories with sources (required)
sonar.sources=coreModule/src/main/java,appModule/src/main/java
sonar.tests=coreModule/src/test/java,appModule/src/test/java

sonar.modules=core,app

core.sonar.projectBaseDir=coreModule
core.sonar.sources=src/main/java
core.sonar.projectName=My Core Module Name
app.sonar.projectBaseDir=appModule
app.sonar.sources=src/main/java
app.sonar.projectName=My App Module Name

# Language
sonar.language=java
sonar.java.source=8

# Encoding of the source files
sonar.sourceEncoding=UTF-8

I figured as much about the wrapper. It hasn't seemed to change anything if I run the scanner after a mvn clean or before, it's there in the target folders but is there a special way to configure it? I had Jenkins setup to run "SonarQube Scanner" at the end of the build. I can get the same results running the command-line scanner locally on demand. — Sloloem

G. Ann - SonarSource Team G. Ann - SonarSource Team · Accepted Answer · 2017-04-26T16:13:39

The SonarQube Scanner for Jenkins is essentially a wrapper around the other scanners to make them available to you conveniently in Jenkins. From the rest of your question, I'll guess that you're using the SonarQube Scanner analysis Build Step in Jenkins.

From the properties you've posted, you don't appear to be providing byte code to SonarQube Scanner analysis. If you were, there would be a sonar.java.binaries property.

The reason the SonarQube Scanner for Maven is finding more issues is that it automatically provides that value to the analysis.

And if you're able to analyze with SonarQube Scanner for Maven, you should. As you've already discovered it "just handles" most of the details for you.

You accomplish this in Jenkins not with a SonarQube Scanner for Maven-specific build step, but with a normal Maven build step. As described in the docs you will have first enabled "Prepare SonarQube Scanner environment" in the Build Environment section. Then you can analyze with $SONAR_MAVEN_GOAL -Dsonar.host.url=$SONAR_HOST_URL. (Note that you may also need to pass an analysis token via -Dsonar.login depending on your project permissions.)

To answer your question, the "extra" issues found by the Maven analysis are legitimate. They are not found by the other analyses because they are raised by rules that work against byte code.

Sonar Maven plugin finds more bugs than Sonar Jenkins or Sonar CLI Scanner on multi-module Maven project

1 Answers