Connect to the wrong Oracle schema
When having 2 Sonar two sonarqube schemas on the same Oracle instance, especially if they are in 2 different versions, Sonar SonarQubeTM can get confused and picks the first it finds. In that case, there are two known workarounds:
1. Remove the DBA rights to the Sonar sonarqube users in Oracle
2. Use sonar.hibernate.default_schema in sonar.properties to set the schema. In that case, -Dsonar.hibernate.default_schema should be used as well during project analysis.
Failed to start on Windows Vista
Sonar SonarQubeTM seems unable to start when installed under the folder "Program Files" in VISTA. It should therefore not be installed there.
Failed to launch the
SonarQubeTM service on Windows platform with a LocalSystem account
This error happens when the temporary file path specified for the Local System doesn't exist. Assuming that environment variables have their default settings and that Windows is installed on the ‘C’ drive, the following paths should exist:
In most cases, the "Temp" folder is missing and should be created. See SONAR-2660.
Failed to start
SonarQubeTM with Oracle due to bad USERS table structure
When another(s) USERS table exists in the Oracle DB, if the sonar sonarqube user has read access on this other USERS table, the Sonar SonarQubeTM web server can't start and an exception like the following one is thrown:
To fix this issue, the rights of the sonar oracle sonarqube Oracle user must be decreased to remove read access on the other(s) USERS table(s).
For some proxies exception "java.net.ProtocolException: Server redirected too many times" might mean incorrect username or password.
SonarQubeTM run in HTTPS mode
No. But you can run Sonar SonarQubeTM in a standard HTTPS infrastructure using reverse proxy (in this case the reverse proxy must be configured to set the value 'X_FORWARDED_PROTO: https' in each HTTP request header. Without this property, redirection initiated by the Sonar SonarQubeTM server will fall back on HTTP).
What is the difference between org.codehaus.mojo:sonar-maven-plugin and org.codehaus.sonar:sonar-maven-plugin?
Here is the rational: Sonar SonarQubeTM needs a Maven plugin to perform analysis of your project. This plugin is part of Sonar SonarQubeTM project so the name of this plugin is org.codehaus.sonar:sonar-maven-plugin because codehaus is hosting the project. Each time there is a new version of SonarSonarQubeTM, there is a new version of the Sonar Maven plugin. For a given version of the Sonar SonarQubeTM server, you MUST run the same version of the Sonar Maven plugin. It means that you would have to run:
if you have installed Sonar SonarQubeTM 2.5.
As this is very annoying to type, you could add the groupId in your settings.xml. This way you could type:
BUT in this case the latest version of the Maven Sonar plugin would be taken. As soon as Sonar SonarQubeTM 2.6 would be released, Maven would automatically use the plugin in version 2.6. If you don't plan to upgrade your Sonar your SonarQubeTM server, it will fail. The answer to this problem is already well-known: define all versions of your plugins in the pom. So you would add:
in all pom (or in corporate pom). And you would have to update your projects each time you are updating sonar SonarQubeTM server. Very annoying but that's not all.
What if you have an integration/acceptance/pre-production instance of Sonar SonarQubeTM in version 2.5, and a production version in version 2.4? You can't analyse the same project with the two instances because you have fixed the version of the sonar Maven plugin to version 2.5 in the pom. You may finally make it works with external properties or any other ugly hack.
The solution proposed by Sonar team is to use a bootstrap plugin. This plugin:
- is hosted in org.codehaus.mojo groupId in order to save the settings.xml configuration
- is supposed to be very stable (ie do not change for each Sonar SonarQubeTM server release)
When you run
. The bootstrap plugin will query Sonar SonarQubeTM server to find its version, then fork a new build to run the normal plugin with
where XX is the version previously returned by the server. This way you can analyse analyze the same project with different versions of Sonar SonarQubeTM and still running the same command line (except Sonar SonarQubeTM hostname of course) and without having to modify the pom.
Most of the time you need latest version of the boostrap plugin, so no need to fix its version in your pom, except if you want to test a particular version (an old one or a SNAPSHOT for example).
Maven mirrors: the maven plugin fails to resolve org.codehaus.sonar.runtime.* dependencies
This issue occurs when using a Sonar version prior to 2.2. To fix it, it's recommended to upgrade Sonar and the maven plugin to version 1.0-beta-2 (for Maven 2 projects) or 2.0-beta-2 (for Maven 3 projects).
Sonar embeds its own maven repository which is used by the Sonar maven plugin to download all Sonar extensions like pmd, checkstyle, findbugs, etc. If you get this error, it's certainly because your Maven configuration prevents Sonar from accessing its own Maven repository. Your maven settings.xml file must certainly contain a section called <mirror> which should look like this :
<mirror> <id>nexus</id> <mirrorOf>*</mirrorOf> <url>http://nexus/</url> <name>Central maven repository</name> </mirror>
According to this section, Maven redirects all calls to the repository called 'nexus', so Sonar maven repository is never touched and Sonar maven plugin fails to resolve org.codehaus.sonar.runtime.* dependencies. Two solutions to solve this issue:
If you have Maven version 2.0.9 or higher, just change the value of <mirrorOf> by
- Or configure your central maven repository (eg. Nexus, Archiva or Artifactory) to use the Sonar internal repository (http://sonar:9000/deploy/maven).
Error resolving version for 'org.codehaus.mojo:sonar-maven-plugin': Plugin requires Maven version 3.0
If you get this error message after launching the maven command line "mvn sonar:sonar" add the "-U" parameter to the command line. Maven will then update its local repository with the latest version of the Sonar Maven plugin.
It means that the analyzer encountered an issue while downloading the plugins from the Sonar SonarQubeTM server to the machine running the project analysis.
- A connection issue with the Sonar SonarQubeTM server. Check with your network administrator.
- A user quota issue. Indeed, by default, all the plugins are downloaded to the local space of the user running the analysis. Some companies set restrictions in terms of local user space, hence the issue. The workaround is to set the 'SONAR_USER_HOME' environment variable on the machine running the analysis to a directory with enough available space to download all the plugins.
Failed to analyse a project as another analysis on the same project seems to be running at the same time (Sonar 3.4 only)
In Sonar SonarQubeTM 3.4 (SONAR-3306) a new semaphore mechanism has been introduced to prevent launching several analysis on the same project in parallel. But in some cases when an analysis of a project is unexpectedly interrupted, the lock of the semaphore is sometimes not released and in such case it's up to the Sonar System administrator to relaunch the project analysis with the property 'sonar.forceAnalysis=true'. This limitation has been fixed in Sonar SonarQubeTM 3.5 (SONAR-4053).
How to remove false positive issues?
You can use the mechanism embedded in rules engine (//NOPMD...) or the generic mechanism implemented in SonarSonarQubeTM: put //NOSONAR at the end of the line of the issue. This will suppress the issue.
The //NOSONAR tag is useful to deactivate all rules at a given line but is not suitable to deactivate all rules (or only a given rule) for all the lines of a method or a class. This is why support for @SuppressWarnings("all") has been added to SonarSonarQubeTM.
Use the Switch Off Violations plugin