Versions Compared

Key

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

Table of Contents

Parameters to configure project analysis of project can be set in various multiple places in Sonar. Here is the hierarchy of parameters:

  • Global analysis parameters, defined in the UI, will apply to all the projects (From the top bar, go to Settings > General Settings)
  • Project analysis parameters, defined in the UI, will override global parameters (At a project level, go to Configuration > Settings)
  • Project analysis parameters, defined in a project analysis configuration file or in an analyzer configuration file, will override the ones defined in the UI
  • Analysis / Command line parameters, defined when launching an analysis, will override project analysis parameters

Note that only parameters set through the UI are stored in the database.
For example, if you override the sonar.exclusions 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 executed with the exclusions defined in the UI and therefore stored in the DB.

Note that the list of parameters below is not exhaustive. The property keys shown in the interface, at both global and project levels, can also be set as analysis parameters.

Mandatory Parameters

...

Server

Key

Description

Default value

sonar.host.urlSonar server Server URLhttp://localhost:9000

Database

Key

Description

Default value

sonar.jdbc.driverClassName 

JDBC Driver used by Sonar

org.h2.Driver

Prior to Sonar 3.2: org.apache.derby.jdbc.ClientDriver

sonar.jdbc.url

JDBC Connection URL

jdbc:h2:tcp://localhost:9092/sonarPrior to Sonar 3.2: jdbc:derby://localhost:1527/

sonarsonar.jdbc.username

User for the JDBC Connection

sonar

sonar.jdbc.password

Password for the JDBC Connection

sonar

Project Configuration

Key

Description

Default value

Version

sonar.projectKey

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.languageSets

Set the language of the source code . If a Sonar plugin allows to analyze another language, the associated source code analyser can be activated with this property.
The default language can be set at instance level: go to Configuration > General Settings > General and set the sonar.language property. 

java

since 2.0

. 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 sourcessource files.
Not compatible Compatible with Maven : since SonarQube 4.2. If not set, the source code is retrieved from the default location for Java Maven projectsMaven source code location

  

Optional Parameters

Project Configuration

sonar.libraries=path/to/specific/library/
*
myLibrary.jar,path/to/
specific/
library/
myLibrary.jar,parent/
*
/*
.jar

Note that the * */ wildcard character is not supported .

Key

Description

Default value

Version

sonar.projectDescription

Description of the The project description.
Set through <description> when using Maven. Not compatible with Maven, which uses the <description> attribute.

  
sonar.binaries

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

  
sonar.tests

Comma-separated paths to directories containing tests.
Not compatible with Maven: tests retrieved from , 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: JAR files). Pattern Patterns can be used.

Example:

Code Block
languagenone
  

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.

 
sonar.analysis.mode

Set the analysis mode. See Concepts.

Possible values:

  • analysis
  • preview
  • incremental
analysis
sonar.preview.readTimeoutThis property is only relevant in the context of preview analysis. In a preview analysis certain information about the project is downloaded from the server into a local database. This property is the timeout value in milliseconds for the reading of that data. Typically the default value is fine, but it may need adjusting in very large or busy environments.
60000

Anchor
parameterSourceEncoding
parameterSourceEncoding
sonar.sourceEncoding

Set the source file encoding.

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.importSourcesSometimes, for

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

since 1.5

(warning) Issue tracking mechanism will not properly work if sources are not imported into SonarQube. For example if you modify a file where some issues were previously flagged as false-positive, those issues will come back again as new issues.

true

Anchor
parameterProjectDate
parameterProjectDate
sonar.projectDate

It becomes quickly necessary to input historical data and to highlight some events. It is possible by going for example in a subversion tag and use the sonar.projectDate option. Format 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-25.

Current date

since 1.5

sonar.exclusions

Exclude files from analysis. This property is usually set in the page Settings of the project. It's a comma separated list of wildcard patterns. Paths are defined from the source base directory. Example: com/mycompany/*.java,**/*Dummy.java.
Complete documentation on the Sonar web interface: go to MyProject > Exclusions.
To exclude a module (Maven module, C# module, etc.), you have to use the sonar.skippedModules property. 

 

since 1.8

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_toexclude,module2_toexclude.

 

since 1.5

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.

 

since 2.2

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.
Note: You must analyze your versions in chronological order, oldest first.

Current date

Anchor
parameterBranch
parameterBranch
sonar.branch

Manage SCM branches. (warning) Two branches of the same project are considered as to be different projects in Sonar.

 

since 1.10

sonar.profile

Through the Sonar SonarQube. As a consequence issues found in a project A in a branch B1 are not linked to issues found for this project A in a branch B2. Currently, there is no way to resolve automatically issues of B2 when they are resolved in B1 as again A-B1 & A-B2 are considered as separated project.

If you are a user of Developer Cockpit, please see "Limitation" section in the Developer Cockpit Installation and Usage

 

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 this these quality profile profiles to a given project . You can also make this association by using the property "sonar.profile".though the web interface.

Default profile for the given language

since 1.6

sonar.skipDesign

Deactivate Java bytecode analysis. Since Sonar 2.0, the java bytecode is analyzed by Sonar in order to extract dependencies between packages and files. Those dependencies are used for instance to display the DSM (Dependency System Matrix). This bytecode analysis can be deactivated.

false

since 2.0

sonar.phase

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

 

since 1.10

sonar.dynamicAnalysis

Dynamic analysis relates to unit tests. By default, those unit tests are executed but you can optionally decide to do only static analysis or to reuse existing reports which have been previously generated. Possible values are true, false, reuseReports.

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

true

since 1.7

Skip the computation of design metrics and dependencies.

Currently only available for Java.

false

Anchor
projectBaseDir
projectBaseDir

sonar.projectBaseDir

Use this property when the files you need analysis to take place in a directory other than the one from which it starts. E.G. analysis begins from jenkins/jobs/myjob/workspace but the files to be analyzed are in ftpdrop/cobol/project1. The path may be relative or absolute.

Specify not the the source directory, but some parent of the source directory. The value specified here becomes the new "analysis directory", and other paths are then specified as though the analysis were starting from the new sonar.projectBaseDir.

Note that the analysis process will need write permissions in this directory; it is where the sonar.working.directory will be created.

 
Anchor
workingDirectory
workingDirectory
sonar.working.directory
To set

Set the working directory for an analysis triggered with the

Sonar

SonarQube Runner or the

Sonar

SonarQube Ant Task (versions greater than 2.0).

.sonar 

Sonar Configuration

Key

Description

Default value

Version

sonar.host.connectTimeoutMs sonar.host.readTimeoutMs

Increasing HTTP timeouts of requests to Sonar server. The Maven plugin executes some HTTP requests to the Sonar server. Two timeouts makes the call fail if the server connection is too slow. In such a case the timeouts can be increased from Maven properties.

respectively 30'000 and 60'000 milliseconds

since 1.12

Path must be relative and unique for each project.

Beware: the specified folder is deleted before each analysis.

.sonar

Exclusions / Inclusions

See Narrowing the Focus to:

  • Exclude files from analysis
  • Prevent some files from being checked for duplications
  • Prevent some files from being taken into account for code coverage by unit tests and integration tests
  • Ignore issues on certain components and against certain coding rules

Analyzer's Log

KeyDescriptionDefault valueVersion
sonar.showProfilingDisplay logs to see where the analyzer spends time.false
sonar.showSqlDisplay all the SQL requests executed on batch sidequeries executed by the analyzer.falsesince Sonar 2.14, Sonar Ant Task 1.4 & Sonar Runner 1.3
sonar.showSqlResultsDisplay the result results of all the SQL requests executed on batch sidequeries executed by the analyzer.falsesince Sonar 2.14, Sonar Ant Task 1.4 & Sonar Runner 1.3
sonar.verboseActivation of the Activate DEBUG mode on batch sidefor the analyzer.falsesince Sonar 2.12, Sonar Ant Task 1.3 & Sonar Runner 1.2