Note that only parameters set through the UI are stored in the database.

For example, if you override the sonar.profile parameter via command line for a specific project, it will not be stored in the database. Local analyses in Eclipse, for example, would still be run against the default quality profile.

Project Configuration

The project key that is unique for each project.Set through <groupId>:<artifactId> when using Maven.

sonar.projectName

Name of the project that will be displayed on the web interface.Set through <name> when using Maven.

sonar.projectVersion

The project version.

Set through <version> when using Maven.

sonar.language

Set the language of the source code to analyze. Browse the Plugin Library page to get the list of all available languages. If not set, a multi-language analysis will be triggered.

sonar.sources

Comma-separated paths to directories containing source files.Compatible with Maven since SonarQube 4.2. If not set, the source code is retrieved from the default Maven source code location.

Optional Parameters

Project Configuration

Key

Description

Default value

sonar.projectDescription

The project description.Not compatible with Maven, which uses the <description> attribute.

sonar.binaries

Comma-separated paths to directories containing the binary files (directories with class files, in the case of Java).Not compatible with Maven, which retrieves binaries from the default location for Java Maven projects.

sonar.tests

Comma-separated paths to directories containing tests.Not compatible with Maven, which retrieves test from the default location for Java Maven projects.

sonar.libraries

Comma-separated paths to files with third-party libraries (JAR files in the case of Java). Patterns can be used.

Example:

Note that the * wildcard character is not supported for directories, only for files.

This property is used by rule engines during issues detection (mainly the SonarQube and FindBugs engines, which both rely on bytecode). Having the bytecode of these libraries allows the rules engines to get more information on coupling, possible null parameters when calling external APIs, etc., thus getting more accuracy during issue detection.

Allow or suppress the import of the text of source files into SonarQube.

For security or other reasons there are times when project sources must not be stored and displayed. Set this value to false to prevent the text of a project's source files from being available via the SonarQube interface to anyone at all.

true

sonar.projectDate

Assign a date to the analysis.

Note: This parameter is applicable to a few, special use cases, rather than being an "every day" parameter:

When analyzing a new project, you may want to retroactively create some history for the project in order to get some information on quality trends over the last few versions.

When moving from one database engine to another, it is highly recommended (even mandatory) to start from a fresh new database schema. In doing so, you will lose the entire history for all your projects. Which is why you may want to feed the new SonarQube database with some historical data.

To answer those use cases, you can use the sonar.projectDate property. The format is yyyy-MM-dd, for example: 2010-12-01.

The process is the following:

Retrieve a the oldest version of your application's source that you wish to populate into the history (from a specific tag, whatever).

Run a SonarQube analysis on this project by setting the sonar.projectDate property. Example: sonar-runner -Dsonar.projectDate=2010-12-01

Retrieve the next version of the source code of your application, update the sonar.projectDate property, and run another analysis. And so on for all the versions of your application you're interested in.

Manage SCM branches. Two branches of the same project are considered to be different projects in SonarQube.

sonar.profile

Override the profile that would normally be used to analyze a project.

Through the web interface, you can define as many quality profiles as you want, and you can easily associate one of these quality profiles to a given project though the web interface.

Default profile for the given language

sonar.skipDesign

Skip the computation of design metrics and dependencies.

Currently only available for Java.

false

sonar.dynamicAnalysis

Enable or disable the execution of unit tests during the analysis.

By default (true) unit tests are executed during a SonarQube analysis. But you can either decide to not execute them (false) or reuse existing reports which have been previously generated (reuseReports).