SonarQube-5.2
Skip to end of metadata
Go to start of metadata

Table of Contents

This analyzer is recommended to launch analysis on Java Maven project.

Prerequisites

You must have previously installed and configured SonarQube Scanner for Maven and read Analyzing Code Source.

Analyzing a Maven Project

Analyzing a Maven project consists of running the Maven goal sonar:sonar in the directory where the pom.xml file sits after having compiled and executed tests:

mvn clean verify sonar:sonar

In some situation you may want to run sonar:sonar goal as a dedicated step. Be sure to use 'install' in the first step to have proper dependency resolution in multi-module projects. Also be aware that additional source folders registered by a plugin (for example build-helper) will not be taken into account during the SonarQube analysis in this case:

mvn clean install
mvn sonar:sonar

If you need to use a specific version of the SonarQube Maven plugin instead of using the latest:

mvn org.codehaus.mojo:sonar-maven-plugin:2.7.1:sonar

See also 'How to Fix Version of Maven Plugin' below.

To get coverage information, you'll need to generate the coverage report before the analysis. See Java Unit Tests and Coverage Results Import and Code Coverage by Integration Tests for Java Project for more information.

Configuring the SonarQube Analysis

A pom.xml file sample is available here.

Additional analysis parameters are listed on the Analysis Parameters page.

Security

Any user who's granted Execute Analysis permission can run an analysis.

If the Anyone group is not granted Execute Analysis permission or if the SonarQube instance is secured (the sonar.forceAuthentication property is set to true), the credentials of a user having been granted Execute Analysis permission have to be provided through the sonar.login and sonar.password properties. Example: sonar-runner -Dsonar.login=myLogin -Dsonar.password=myPassword

Note that for a preview analysis, the user also has to be granted the Browse permission on the project to be analyzed.

Excluding a module from SonarQube analysis

You can either:

  • define property <sonar.skip>true</sonar.skip> in the pom.xml of the module you want to exclude
  • use build profiles to exclude some module (like for integration tests)
  • use Advanced Reactor Options (such as "-pl"). For example mvn sonar:sonar -pl !module2

Sample Projects

To help you get started, a simple project sample is available on github that can be browsed or downloaded: projects/languages/java/maven/java-maven-simple

How to Fix Version of Maven Plugin

It is recommended to lock down versions of Maven plugins:

Project analyzed with Maven 3

<build>
  <pluginManagement>
    <plugins>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>sonar-maven-plugin</artifactId>
        <version>2.7</version>
      </plugin>
    </plugins>
  </pluginManagement>
</build>

Analyzing a Multi-language Project

By default the sonar.sources property is set to the value of the Maven sourceDirectory property (by default it is src/main/java) plus pom.xml (and also src/main/webapp is automatically added for war modules). Therefore, for a multi-language project, the property usually has to be overridden to: sonar.sources=src/main,pom.xml.

To help you get started, a multi-language project sample can be browsed or downloaded from github: projects/languages/multi-language/multi-language-java-javascript-maven

Converting a Mono-language Project to a Multi-language Project

Let's take as an example a project containing both Java and JavaScript source code. Your SonarQube instance currently contains two different projects: one for the Java source code and one for the JavaScript source code. Optionally, you may also have created a view to aggregate these two projects.

The first step is to choose which one of these two mono-language projects you will convert to a multi-language project. You will lose the history (timeline, false positives, action plans, etc.) on the one that won't get converted to a multi-language project. In this example, we'll choose to convert the Java project to a multi-language project as most of our code (and therefore history) is Java.

The second step is to run another analysis of this Java project the old way (make sure to explicitly set the sonar.language property to java). This step is mandatory to keep the history on the project.

The third and last step is to remove the sonar.language property and set the sonar.sources property to the parent directory containing all your source code (Java + JavaScript). You can now run another analysis. You will finally be able to browse your first multi-language project!

 

  • No labels