Connect to the wrong Oracle schema
When having 2 Sonar schema on the same Oracle instance, especially if they are in 2 different versions, Sonar can get confused and picks the first it finds. In that case, there are two known work around :
1. Remove the DBA rights to the Sonar 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 seems unable to start when installed under the Folder Program Files in VISTA. It should therefore not be installed there.
Cannot connect to MySQL database
By default, remote access to MySQL database server is disabled for security reasons. If you want to remotely access to the database server from the Sonar Maven plugin, you need to follow this quick guide.
I have locked myself out
There is currently nothing that stops you removing from every user and every group the global administrator role. the global administrator role. You then have no other solution than make an manual update in the Sonar database to get back in control.
I am not getting expected new violations in the differential views of drill-down ?
3 reasons can explain this :
- This service only shows "Added Violations", not fixed ones. Therefore the number you see in this service can be different from the dashboard.
- The algorithm used to detect if a violation is new is very good but still perfectible. Therefore new violations can sometimes appear only because Sonar did not recognize it existed already
- You are looking at a period of X days which goes beyond the first analysis made after migration to Sonar 2.5. In this case there can be a discrepancy due to the fact that prior to 2.5, Sonar was not collecting the info necessary to build this service. This issue will disappear as soon as period does not go beyond first analysis.
How to remove false-positive violations ?
You can use the mechanism embedded in underlying rules violation engine (//NOPMD...) or the generic mechanism implemented in Sonar : Put //NOSONAR at the end of the line of the violation. This will suppress the violation.
I lost the admin password
In case you lost the admin password of your Sonar instance, you can reset it by running the following update statement :
This will reset the password to admin.
Maven mirrors : the maven plugin fails to resolve org.codehaus.sonar.runtime.* dependencies
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 :
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). If you use Nexus, take a look to the section "Declare the Sonar Maven Repository inside Nexus" in the Full installation in 5 steps.
Error resolving version for 'org.codehaus.mojo:sonar-maven-plugin': Plugin requires Maven version 3.0
This error means that you're using Maven 2.0.10 or Maven 2.0.11. Due to SONAR-1994, you must add the following lines to the pom.xml file :
Corbertura exception on Linux System while accessing the cobertura.ser file
When reading the cobertura.ser file, the Cobertura Maven plugin tries to get a lock on that file. This locking mechanism generates an exception on Linux Systems SONAR-172.
The current workaround is to add the following lines to the pom.xml file (thanks to Wouter de Vaal) :
The plugin 'org.apache.maven.plugins:maven-sonar-plugin' does not exist or no valid version could be found
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.
If adding the "-U" parameter doesn't fix your issue, you've certainly encountered Maven bug MNG-4001. The only known workaround is to delete the org\codehaus\mojo directory in your local Maven repository. Of course, if your local Maven repository is synchronized with a repository manager like Nexus, this operation must be also done on the repository manager side.
Maven fails with an OutOfMemoryError
Increase the maven available memory by setting the environment variable :
Maven fails with a SecurityException
The message of the root exception is
The CGLIB library available in your Maven repository is certainly signed which is not the case on IBIBLIO repository. Perhaps you or your Maven administrator have signed this jar to include it into a Java Web Start application. Unfortunately signing CGLIB jar file breaks Hibernate's use of CGLIB, as it generates proxy classes in the same package (org.sonar.commons.database.* for our context) as the original class. But the original Sonar class is not signed and the new proxy class is, generating a java.lang.SecurityException.
You must also sign Sonar libraries in your Maven repository or used unsigned CGLIB library.
Maven fails because of Maven Enforcer violations
You have to add the parameter -Denforcer.skip=true to the Maven command-line.
Failed to resolve stax2-api artifact
The following error occurs when using Maven Archiva 1.1. It must be upgraded to 1.2.1.
Findbugs fails on timeout
See SONAR-1439. Findbugs fails with the following logs :
Add the findbugs-maven-plugin to the plugins section of the pom and configure the parameter "timeout".
Java heap space whilst running CpdSensor
Running CPD to find copy paste of source is a memory hungry process and requires sometimes too much resources on very big projects. It is therefore possible to skip copy paste detection by going to configuration -> settings -> Duplications
0% code coverage reported whereas unit tests are correctly executed
This problem occurs when using the Maven Cobertura Plugin and a special configuration of the Maven Surefire Plugin preventing unit tests to be forked. This problem can be solved by removing the line "<forkMode>never</forkMode>" in the Maven configuration file (see SONAR-1445 and MCOBERTURA-70).
My project only builds with JDK1.4
As Sonar can only run with JDK1.5 or higher, some configuration should be added to the pom.xml to indicate that the project requires JDK1.4: