The Sonar SonarQube Runner is recommended as the default launcher to analyze a project with SonarSonarQube.
This page describes how to use the Sonar Runner 2.0+
Create a configuration file in the root directory of the project: sonar-project.properties
# requiredRequired metadata sonar.projectKey=my:project sonar.projectName=My project sonar.projectVersion=1.0 # pathPath to the parent 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 and path to directory of classes are supported. sonar.libraries=path/to/library/*.jar,path/to/classes/dir # The value of the property must be the key of the language. sonar.language=cobolcode directory. # Path is relative to the sonar-project.properties file. Replace "\" by "/" on Windows. # Since SonarQube 4.2, this property is optional. If not set, SonarQube starts looking for source code # from the directory containing the sonar-project.properties file. sonar.sources=src # Encoding of the source code sonar.sourceEncoding=UTF-8 # Additional parameters sonar.my.property=value
Run the following command from the project base directory to launch the Sonar analysis:
Since Sonar 3.4, if you have set the security property 'sonar.forceAuthentication' to 'true', to run the analysis, you have to set the 'sonar.login' and 'sonar.password' properties to an existing user, either:
- directly on the command line by adding -Dsonar.login=myUser -Dsonar.password=myPassword
- or by setting these two properties in the sonar-project.properties file or in the sonar-runner.properties file
Since SonarQube 4.2, it is possible to run an analysis on a multi-language project. To do so, the
sonar.language property just has to be removed. Conversely, if for some reason you want to perform a single language-only analysis, make sure
sonar.language is specified.
There are two ways to define a multi-module structure in SonarSonarQube:
|Using the given file structure...||... with the given 'properties' files|
Set all the configuration in the properties file in the root folder
Set the configuration in multiple properties files
- Properties are inherited from parent to children
They can obviously 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 '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 '
For instance, here are two use cases and the way how to redefine the base directory of the modules in each:
the folder of a module contains white spaces or special characters:
Code Block language bash
module1.sonar.projectBaseDir=My Module One
the module is not located directly in the parent folder, but in a deeper directory structure:
Code Block language bash
- A project that defines modules (or a module that defines sub-modules) cannot define a source code folder to be analyzed by Sonar.
- 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 Sonar 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:
Running Other Tasks
# 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 developer data (Developer Cockpit plugin is required) sonar-runner devcockpit
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 language none
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 and
Code Block language none
The Sonar working directory can be set through the 'sonar.working.directory' property (default is '.sonar').The root folder of the project to analyze can be set through the '
sonar.projectBaseDir property since SonarQube Runner 2.4 (was previously
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.
If you get an a Java heap space error or java.lang.OutOfMemoryError, you can set increase the memory via the SONAR_RUNNER_OPTS environment variable, like this in *nix environments:
On Windows environments, avoid the double-quotes, since they get misinterpreted , turning and combine the two parameters into a single one.
Migrating from Sonar Runner 1.X to Sonar 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