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
- Project analysis parameters, defined in the UI, will override global parameters
- 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
sonar.profileparameter 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.
|Sonar server Server URL||http://localhost:9000|
JDBC Driver used by Sonar
Prior to Sonar 3.2: org.apache.derby.jdbc.ClientDriver
JDBC Connection URL
jdbc:h2:tcp://localhost:9092/sonarPrior to Sonar 3.2: jdbc:derby://localhost:1527/
User for the JDBC Connection
Password for the JDBC Connection
The project key that is unique for each project.
Name of the project that will be displayed on the web interface.
The project version.
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.
. Browse the Plugin Library page to get the list of all available languages.
Comma-separated paths to directories containing sourcessource files.
Description of the The project description.
Comma-separated paths to directories containing binaries (in the binary files (directories with class files, in the case of Java: directories with class files).
Comma-separated paths to directories containing tests.
Comma-separated paths to files with third-party libraries (JAR files in the case of Java: JAR files). Pattern Patterns can be used.
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.
Set the analysis mode. See Concepts.
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
The list of available encodings depends on your JVM. See http://docs.oracle.com/javase/1.5.0/docs/guide/intl/encoding.doc.html.
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.
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:
To answer those use cases, you can use the sonar.projectDate property. The format is
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.
Some project modules should not be analyzed and consolidated with global project measures, for instance samples, integration tests or generated code.
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.
The process is the following:
Note: You must analyze your versions in chronological order, oldest first.
Manage SCM branches. Two branches of the same project are considered as to be different projects in SonarSonarQube.
Override the profile that would normally be used to analyze a project.
Through the Sonar 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
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.
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. Skip the computation of design metrics and dependencies.
Currently only available for Java.
Execute a Maven phase or goal prior to the analysis.
analysis relates to Enable or disable the execution of unit tests during the analysis.
By default , those (
See the Code Coverage by Unit Tests tutorial for details and examples.
|To set |
Set the working directory for an analysis triggered with theSonar
SonarQube Runner or theSonar
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 Narrowing the Focus documentation page.
Exclude files from analysis. See also
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
|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. See also |
|Display logs to see where the analyzer spends time.|
|Display all the SQL requests executed on batch sidequeries executed by the analyzer.||since Sonar 2.14, Sonar Ant Task 1.4 & Sonar Runner 1.3|
|Display the result results of all the SQL requests executed on batch sidequeries executed by the analyzer.||since Sonar 2.14, Sonar Ant Task 1.4 & Sonar Runner 1.3|
|Activation of the Activate DEBUG mode on batch sidefor the analyzer.||since Sonar 2.12, Sonar Ant Task 1.3 & Sonar Runner 1.2|