Versions Compared


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


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


For example, if you override the sonar.profileexclusions 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.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





Default value


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


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

The project version.
Set through <version> when using Maven.


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



Comma-separated paths to directories containing source files.
Not compatible Compatible with Maven , which retrieves 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


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.




Default value


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


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. 


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


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


Code Block

Set the analysis mode. See Concepts.

Possible values:

  • analysis
  • preview
  • incremental
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.


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 in Maven projects.

The list of available encodings depends on your JVM. See

System encoding


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.

(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. For this reason, this property has been deprecated in SonarQube 4.5.1 and the related feature will be removed in SonarQube 5.0.



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

Current date


Manage SCM branches. (warning) Two branches of the same project are considered to be different projects in 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



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.

Note that this property is deprecated (see

) and will be removed in a near future.

Default profile for the given language


Skip the computation of design metrics and dependencies.

Currently only available for Java.




Execute a Maven phase or goal prior to the analysis.

For example sonar.phase=generate-sources. This property is used only for Maven analysis.



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

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


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 will be created.


Set the working directory for an analysis triggered with 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 each analysis.


Exclusions / Inclusions



The below properties are detailed on the See Narrowing the Focus documentation page.






Default value


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

Display logs to see where the analyzer spends time.

Since SonarQube 5.0, this parameter is generating a file containing these timing infos in

<workingDir>/profiling/<moduleKey>-profiler.xml where <workingDir> is:
  • .sonar/profiling/ when analysis is run with Sonar Runner
  • target/sonar/profiling/ when Maven is used 
sonar.showSqlDisplay all the SQL queries executed by the analyzer.false
sonar.showSqlResultsDisplay the results of all the SQL queries executed by the analyzer.false
sonar.verboseActivate DEBUG mode for the analyzer.false