See https://docs.sonarqube.org/display/SONAR/Documentation for current functionality
Mono-language / Multi-language Analysis Mode
sonar.language property is set, the behavior remains exactly the same as for versions prior to 4.2: the multi-language analysis mode is not activated. However, as a consequence of the change to multi-language analysis, "language" will no longer be recorded for a project. This means that language will no longer be displayed in the description widget, nor will it be available in the Measures Service for project searches.
Note that the
sonar.language property doesn't have a default value anymore (was previously set to
java by default). It means that your Java projects may not explicitly set this property to
java. Therefore, to keep analyzing in the mono-language mode, make sure to explicitly set this property to
- Do not set the
- Set the
sonar.sourcesproperty to the parent directory containing all your source code.
- Run an analysis
Converting a Mono-language Project to a Multi-language Project
The first step is to choose which one of these two mono-language projects you will convert to a multi-language project. You will lose the history (timeline, false positives, action plans, etc.) on the one that won't get converted to a multi-language project. In this example, we'll choose to convert the Java project to a multi-language project as most of our code (and therefore history) is Java.
The second step is to run another analysis of this Java project the old way (make sure to explicitly set the
sonar.language property to
java). This step is mandatory to keep the history on the project.
The third and last step is to remove the
sonar.language property and set the
SonarQube Java 2.1
SonarQube 4.2 is compatible with SonarQube Java 2.1, and is not backwards-compatible with previous versions of the Java Ecosystem. Conversely, SonarQube Java 2.1 is compatible with SonarQube 4.2, and not with previous versions.
When using an external authentication mechanism like LDAP, the
sonar.security.localUsers property must be set in $SONARQUBE_HOME/conf/sonar.properties to the list of all the technical accounts (comma-separated list). These accounts will not be authenticated against LDAP but against the SonarQube engine. Conversely, all accounts not flagged as local will only be authenticated against the external authentication, although the "fallback" to the SonarQube database authentication will still be available when LDAP, for instance, is unavailable.
admin is a technical account.
Because the component keys are computed differently in SonarQube 4.2, you might have to update your exclusions. See Narrowing the Focus#Patterns.
sonar.jdbc.schema property is deprecated
Read Installing the Server#installingDatabaseInstallingtheDatabase to configure SonarQube without using this property.