Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 143 Next »

Table of Contents

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


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


Simple Project

Create a configuration file in the root directory of the project:

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


SonarQube 3.7+

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

SonarQube 3.4 to 3.6.3

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=myLogin -Dsonar.password=myPassword
  • or in the build.xml file

A project cannot be anonymously accessed when either:

Prior to SonarQube 3.4

There is no security restriction.

Project Samples

To help you get started, simple project samples are available for most languages on github. They can be browsed or downloaded. You'll find them filed under projects/languages.

Multi-module Project

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

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

Way #1

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

"MyProject/" file content

Way #2

Set the configuration in multiple properties files

"MyProject/" file content
"MyProject/module1/" file content
"MyProject/module2/" file content



  • Children inherit their parent's properties 
    Inherited properties can be overriden:
    • By prefixing them with the module identifier (way #1)
    • Simply by defining them in the 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 how to redefine the base directory of the modules in each:
    • the folder of a module contains white spaces or special characters:


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


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

To help you get started, multi-module project samples can be browsed or downloaded from github:

  • Modules with the same structure: projects/multi-module/sonar-runner/java-sonar-runner-modules-same-structure
  • Modules with different structures: projects/multi-module/sonar-runner/java-sonar-runner-modules-different-structures
  • A configuration file for each module: projects/multi-module/sonar-runner/java-sonar-runner-modules-own-configuration-file

Multi-module and Multi-language Project

Since SonarQube 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:


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

Running Other Tasks

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

Advanced Usage

If a 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:


  • 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:


The root folder of the project to analyze can be set through the 'project.home' property. This folder must contain a 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. 



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

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

Migrating from SonarQube Runner 1.X to SonarQube Runner 2.0

Replace the following properties in the file:

  • sources => sonar.sources
  • tests => sonar.tests
  • binaries => sonar.binaries
  • libraries => sonar.libraries
Explicitly set the sonar.sourceEncoding property in the file.
  • No labels