Message-ID: <845395079.1505.1425442989456.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_1504_1581754356.1425442989455" ------=_Part_1504_1581754356.1425442989455 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
sonar.language property is set, the behavior remai=
ns exactly the same as for versions prior to 4.2: the multi-language analys=
is mode is not activated. However, as a consequence of the change to multi-=
language analysis, "language" will no longer be recorded for a pr=
oject. This means that language will no longer be displayed in the descript=
ion widget, nor will it be available in the Measures Service for project se=
Note that the
sonar.language property doesn't have a defaul=
t value anymore (was previously set to
java by default). It me=
ans that your Java projects may not explicitly set this property to
ava. Therefore, to keep analyzing in the mono-language mode, make su=
re to explicitly set this property to
sonar.sourcesproperty to the parent directory con= taining all your source code.
The first step is to choose which one of these two mono-language project= s 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 co= nverted to a multi-language project. In this example, we'll choose to conve= rt the Java project to a multi-language project as most of our code (and th= erefore history) is Java.
The second step is to run another analysis of this Java project the old =
way (make sure to explicitly set the
java). This step is mandatory to keep the his=
tory on the project.
The third and last step is to remove the
sonar.language property and set the
sonar.sources property t=
You can now run another analysis. You will finally be able to browse your =
first multi-language project!
SonarQube 4.2 is compatible with SonarQube Java 2.1, and is not backwards-compatible with prev= ious 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
operty 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. Co=
nversely, all accounts not flagged as local will only be authenticated agai=
nst the external authentication, although the "fallback" to the S=
onarQube database authentication will still be available when LDAP, for ins=
tance, is unavailable.
admin is a technical account.
Because the component keys are computed differently in SonarQube 4.2, yo= u might have to update your exclusions. See Narrowing the Focus.
sonar.jdbc.schemaproperty is deprecated
Read Installing to conf= igure SonarQube without using this property.