Configuring a Project to Exclude Certain Sonar Violations

1. Overview

During our builds, we can use various tools to report on the quality of our source code. One such tool is SonarQube, which performs static code analysis.

Sometimes we may disagree with the results returned. We may, therefore, wish to exclude some code that has been incorrectly flagged by SonarQube.

In this short tutorial, we’ll look at how to disable Sonar checks. While it’s possible to change the ruleset on the SonarQube’s server, we’ll focus only on how to control individual checks within the source code and configuration of our project.

2. Violation Example

Let’s look at an example:

public void printStringToConsoleWithDate(String str) {
    System.out.println(LocalDateTime.now().toString() + " " + str);
}

By default, SonarQube reports this code as a Code Smell due to the java:S106 rule violation:

However, let’s imagine that for this particular class, we’ve decided that logging with System.out is valid. Maybe this is a lightweight utility that will run in a container and does not need a whole logging library just to log to stdout.

We should note that it’s also possible to mark a violation as a false-positive within the SonarQube user interface. However, if the code is analyzed on multiple servers, or if the line moves to another class after refactoring, then the violation will re-appear.

Sometimes we want to make our exclusions within the source code repository so that they persist.

So, let’s see how we can exclude this code from the SonarQube report by configuring the project.

3. Using //NOSONAR

We can disable a single line of code by putting a //NOSONAR at the end:

System.out.println(
  LocalDateTime.now()
    .toString() + " " + str); //NOSONAR lightweight logging

The //NOSONAR tag at the end of the line suppresses all issues that might be raised on it. This approach works for most languages supported by SonarQube.

We’re also allowed to put some additional comments after NOSONAR explaining why we have disabled the check.

Let’s move forward and take a look at a Java-specific way to disable checks.

4. Using @SuppressWarnings

4.1. Annotating the Code

In Java, we can exclude Sonar checks using the built-in @SuppressWarnings annotation.

We can annotate the function:

@SuppressWarnings("java:S106")
public void printStringToConsoleWithDate(String str) {
    System.out.println(LocalDateTime.now().toString() + " " + str);
}

This works exactly the same way as suppressing compiler warnings. All we have to do is specify the rule identifier, in this case java:S106.

4.2. How to Get the Identifier

We can get the rule identifier using the SonarQube user interface. When we’re looking at the violation, we can click Why is this an issue?:

It shows us the definition. From this we can find the rule identifier in the top right corner:

5. Using sonar-project.properties

We can also define exclusion rules in the sonar-project.properties file using analysis properties.

Let’s define and add the sonar-project.properties file to our resource dir:

sonar.issue.ignore.multicriteria=e1

sonar.issue.ignore.multicriteria.e1.ruleKey=java:S106
sonar.issue.ignore.multicriteria.e1.resourceKey=**/SonarExclude.java

We’ve just declared our very first multicriteria, named e1. We excluded the java:S106 rule for the SonarExclude class. Our definition can mix exclusions using rule identifiers and file matching patterns together, respectively in ruleKey and resourceKey properties preceded by the e1 name tag.

Using this approach, we can build a complex configuration that excludes particular rules across multiple files:

sonar.issue.ignore.multicriteria=e1,e2

# Console usage - ignore a single class
sonar.issue.ignore.multicriteria.e1.ruleKey=java:S106
sonar.issue.ignore.multicriteria.e1.resourceKey=**/SonarExclude.java
# Too many parameters - ignore the whole package
sonar.issue.ignore.multicriteria.e2.ruleKey=java:S107
sonar.issue.ignore.multicriteria.e2.resourceKey=com/baeldung/sonar/*.java

We’ve just defined a subset of multicriteria. We extended our configuration by adding a second definition and named it e2. Then we combined both rules in a single subset, separating the names with a comma.

6. Disable Using Maven

All analysis properties can be also applied using Maven properties. A similar mechanism is also available in Gradle.

6.1. Multicriteria in Maven

Returning to the example, let’s modify our pom.xml:

<properties>
    <sonar.issue.ignore.multicriteria>e1</sonar.issue.ignore.multicriteria>
    <sonar.issue.ignore.multicriteria.e1.ruleKey>java:S106</sonar.issue.ignore.multicriteria.e1.ruleKey>
    <sonar.issue.ignore.multicriteria.e1.resourceKey>
      **/SonarExclude.java
    </sonar.issue.ignore.multicriteria.e1.resourceKey>
</properties>

This configuration works exactly the same as if it were used in a sonar-project.properties file.

6.2. Narrowing the Focus

Sometimes, an analyzed project may contain some generated code that we want to exclude and narrow the focus of SonarQube checks.

Let’s exclude our class by defining sonar.exclusions in our pom.xml:

<properties>
    <sonar.exclusions>**/SonarExclude.java</sonar.exclusions>
</properties>

In that case, we’ve excluded a single file by its name. Checks will be performed for all files except that one.

We can also use file matching patterns. Let’s exclude the whole package by defining:

<properties>
    <sonar.exclusions>com/baeldung/sonar/*.java</sonar.exclusions>
</properties>

On the other hand, by using the sonar.inclusions property, we can ask SonarQube only to analyze a particular subset of the project’s files:

<properties>
    <sonar.inclusions>com/baeldung/sonar/*.java</sonar.inclusions>
</properties>

This snippet defines analysis only for java files from the com.baeldung.sonar package.

Finally, we can also define the sonar.skip value:

<properties>
    <sonar.skip>true</sonar.skip>
</properties>

This excludes the whole Maven module from SonarQube checks.

7. Conclusion

In this article, we discussed different ways to suppress certain SonarQube analysis on our code.

We started by excluding checks on individual lines. Then, we talked about built-in @SuppressWarnings annotation and exclusion by a specific rule. This requires us to find the rule’s identifier.

We also looked at configuring the analysis properties. We tried multicriteria and the sonar-project.properties file.

Finally, we moved our properties to the pom.xml and reviewed other ways to narrow the focus.