Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Info
iconfalse
titleTable of Contents

Table of Contents
maxLevel2

The SonarQubeTM Runner is recommended as the default launcher to analyze a project with SonarQubeTM.

Prerequisites

You must have previously installed the SonarQubeTM Runner and read Analyzing Code Source.

Usage

Simple Project

Create a configuration file in the root directory of the project: sonar-project.properties

Code Block
titlesonar-project.properties
languagebash
# required metadata
sonar.projectKey=my:project
sonar.projectName=My project
sonar.projectVersion=1.0

# optional description
sonar.projectDescription=Fake description

# path to source directories (required)
sonar.sources=srcDir1,srcDir2

# path to test source directories (optional)
sonar.tests=testDir1,testDir2

# path to project binaries (optional), for example directory of Java bytecode
sonar.binaries=binDir

# optional comma-separated list of paths to libraries. Only path to JAR file is supported.
sonar.libraries=path/to/library/*.jar,path/to/specific/library/myLibrary.jar,parent/*/*.jar

# The value of the property must be the key of the language.
sonar.language=cobol

# Additional parameters
sonar.my.property=value

Run the following command from the project base directory to launch the analysis:

Code Block
languagenone
sonar-runner

Security

Since SonarQubeTM 3.4, if a project cannot be accessed anonymously, the sonar.login and sonar.password properties are required to run an analysis on this project. These properties have to be set to the credentials of a user having the 'User' role on this project. You can set them either:

  • directly on the command line by adding -Dsonar.login=myUser -Dsonar.password=myPassword
  • or in the sonar-project.properties project configuration file
  • or in the sonar-runner.properties global configuration file

A project cannot be anonymously accessed when either:

Project Samples

To help you getting started, for each language, a simple project sample is available on github that can be browsed or downloadedprojects/languages

Multi-module Project

There are two ways to define a multi-module structure in SonarQubeTM:

 Using the given file structure...... with the given 'properties' files

Way #1

Set all the configuration in the properties file in the root folder

Code Block
title"MyProject/sonar-project.properties" file content
linenumberstrue
languagebash
# Root project information
sonar.projectKey=org.mycompany.myproject
sonar.projectName=My Project
sonar.projectVersion=1.0-SNAPSHOT

# Some properties that will be inherited by the modules
sonar.sources=src

# List of the module identifiers
sonar.modules=module1,module2

# Properties can obviously be overriden for
# each module - just prefix them with the module ID
module1.sonar.projectName=Module 1
module2.sonar.projectName=Module 2

Way #2

Set the configuration in multiple properties files

Code Block
title"MyProject/sonar-project.properties" file content
linenumberstrue
languagebash
# Root project information
sonar.projectKey=org.mycompany.myproject
sonar.projectName=My Project
sonar.projectVersion=1.0-SNAPSHOT

# Some properties that will be inherited by the modules
sonar.sources=src

# List of the module identifiers
sonar.modules=module1,module2
Code Block
title"MyProject/module1/sonar-project.properties" file content
linenumberstrue
languagebash
# Redefine properties
# Note that you do not need to prefix the property here
sonar.projectName=Module 1
Code Block
title"MyProject/module2/sonar-project.properties" file content
linenumberstrue
languagebash
# Redefine properties
# Note that you do not need to prefix the property here
sonar.projectName=Module 2

 

Noteworthy:

  • Properties are inherited from parent to children 
    They can obviously be overriden:
    • By prefixing them with the module identifier (way #1)
    • Simply by defining them in the sonar-project.properties file located in the module (way #2)

  • Module base directory can be specified for special cases
    By default, the module base directory is guessed from the module identifier (like in the examples above). But it can be redefined using the sonar.projectBaseDir property.
    For instance, here are two use cases and the way to redefine the base directory of the modules:
    • the folder of a module contains white spaces or special characters:

      Code Block
      languagebash
      module1.sonar.projectBaseDir=My Module One

        

    • the module is not located directly in the parent folder, but in a deeper directory structure:

      Code Block
      languagebash
      module1.sonar.projectBaseDir=modules/mod1
      module2.sonar.projectBaseDir=modules/mod2

        

  • A project that defines modules (or a module that defines sub-modules) cannot define a source code folder to be analyzed.
     

To help you getting started, multi-module project samples are available on github that can be browsed or downloaded:

Multi-module and Multi-language Project

Since SonarQubeTM 3.3, it is possible to run an analysis on a multi-module project whose modules contains source code from different languages.

In addition to the multi-module configuration, the only mandatory property to set is the language for each module:

Code Block
titlemodule.sonar.language
linenumberstrue
languagebash
module1.sonar.language=java
module2.sonar.language=js
...

To help you getting started, a multi-language project sample is available on github that can be browsed or downloadedprojects/languages/multi-language/multi-language-java-javascript-sonar-runner

Running Task

Before SonarQubeTM 3.6, it was only possible to run a project analysis. Since SonarQubeTM 3.6, it is possible to run other tasks such as:

Code Block
languagenone
# To run the computation of views (Views plugin is required)
sonar-runner views

# To run the computation of reports (Report plugin is required)
sonar-runner report

# To run the computation of developers data (Developer Cockpit plugin is required)
sonar-runner devcockpit

Advanced Usage

If a sonar-project.properties file cannot be created in the root directory of the project, there are several alternatives:

  • The properties can be specified directly through the command line. Ex:

    Code Block
    languagenone
    sonar-runner -Dsonar.projectKey=myproject -Dsonar.sources=src1

      

  • The property 'project.settings' can be used to specify the path to the project configuration file (this option is incompatible with the 'project.home' property). Ex:

    Code Block
    languagenone
    sonar-runner -Dproject.settings=../myproject.properties

      

The root folder of the project to analyze can be set through the 'project.home' property. This folder must contain a sonar-project.properties file if the mandatory properties (like sonar.projectKey) are not specified on the command line.

Additional analysis parameters can be defined in this project configuration file or through command-line parameters. 

Troubleshootings

Note

If you get an java.lang.OutOfMemoryError, you can set the SONAR_RUNNER_OPTS environment variable, like this in *nix environments:

Code Block
languagenone
export SONAR_RUNNER_OPTS="-Xmx512m -XX:MaxPermSize=128m"

On Windows environments, avoid the double-quotes, since they get misinterpreted, turning the two parameters into a single one.

Code Block
languagenone
set SONAR_RUNNER_OPTS=-Xmx512m -XX:MaxPermSize=128m

Migrating from SonarQubeTM Runner 1.X to SonarQubeTM Runner 2.0

Replace the following properties in the sonar-project.properties file:

  • sources => sonar.sources
  • tests => sonar.tests
  • binaries => sonar.binaries
  • libraries => sonar.libraries
Explicitly set the sonar.sourceEncoding property in the sonar-project.properties file.