Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Key

Description

Default value

sonar.projectDescription

Description of the project.
Set through <description> when using Maven. 

 
sonar.binaries

Comma-separated paths to directories containing binaries (in case of Java: directories with class files).
Not compatible with Maven: binaries retrieved from default location for Java Maven projects. 

 
sonar.tests

Comma-separated paths to directories containing tests.
Not compatible with Maven: tests retrieved from default location for Java Maven projects.  

 
sonar.libraries

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

Example:

Code Block
languagenone
sonar.libraries=path/to/specific/library/myLibrary.jar,path/to/library/*.jar

Note that * wildcard character is not supported for directories (only for files).

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

 
sonar.analysis.mode

Analysis mode. See Concepts.

Possible values:

  • analysis
  • preview
  • incremental
analysis

Anchor
parameterSourceEncoding
parameterSourceEncoding
sonar.sourceEncoding

Encoding of source files. Example of values: UTF-8, MacRoman, Shift_JIS. This property can be replaced by the standard property project.build.sourceEncoding in Maven projects.

The list of available encodings depends on your JVM. See http://docs.oracle.com/javase/1.5.0/docs/guide/intl/encoding.doc.html.

System encoding

sonar.importSources

Sometimes, for security or other reasons, project sources must not be stored and displayed.

true

Anchor
parameterProjectDate
parameterProjectDate
sonar.projectDate

When starting to analyze a new project, you may want to feed your SonarQube instance with the quality snapshots of the last versions of this project. In order to get some information on quality trend over the last versions.

When moving from one database engine to another, it is highly recommended (even mandatory) to start from a fresh new database schema. In this case, you will lose your whole history. So, you may also want to feed the new SonarQube instance with some historical data.

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

The process is the following:

  • Retrieve a specific version of the source code of your application from the SCM (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 another version of the source code of your application from the SCM and run another analysis by properly setting the sonar.projectDate property. And so on for all the versions of your application you're interested in.
Note: first analyze the latest version and then move in chronological order to the newest one.

 

Current date

sonar.exclusions

Exclude files from analysis. See Project Administration for more details. This page also details sonar.tests.exclusions, sonar.inclusions, sonar.tests.inclusions, sonar.global.exclusions, sonar.global.tests.exclusions.

 

sonar.skippedModules

Some project modules should not be analyzed and consolidated with global project measures, for instance samples, integration tests or generated code.
If a module's artifactId differs from its module name (the directory name): it is the artifactId that should be use instead of the module name. Format is a comma-separated list of modules: module1_to_exclude,module2_to_exclude.

 

sonar.includedModules

Comma-separated list of the modules to analyse, all other modules are automatically ignored. Be careful: the root project must be added to the list.
If a module's artifactId differs from its module name (the directory name): it is the artifactId that should be use instead of the module name.

 

Anchor
parameterBranch
parameterBranch
sonar.branch

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

 

sonar.profile

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.

Default profile for the given language

sonar.skipDesign

To skip the computation of design metrics and dependencies.

Currently only available for Java.

false

sonar.phase

When SonarQube needs a Maven phase or goal to be executed prior to the analysis, this parameter can be used. For example sonar.phase=generate-sources. This property is used only for Maven analysis.

 

sonar.dynamicAnalysis

Dynamic analysis relates to unit tests. 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).

See the Code Coverage by Unit Tests tutorial for details and examples.

true

Anchor
workingDirectory
workingDirectory
sonar.working.directory

To set the working directory for the analysis triggered wit the SonarQube Runner or the SonarQube Ant Task (versions greater than 2.0).

Path must be relative and unique for each project.

Beware: the specified folder is deleted before running each analysis.

.sonar

...