Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Info
iconfalse
titleTable of Contents
Table of Contents

Installation

Connect to the wrong Oracle schema

When having 2 Sonar schemas 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 workarounds:
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.

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.

Failed to start on 64-bit Windows 7

If you have installed a 64-bit version of the JDK or JRE, and Windows is using the 64-bit version by default, then the batch file windows-x86-32\StartSonar.bat will not start the server because the wrapper.exe program called by the batch file cannot load the lib\wrapper.dll library. You can check which version of Java is being used by opening a shell and typing "java -version". If it is a 64-bit version you will see something like "Java HotSpot (TM) 64-Bit Server VM" in the description. You can download a 32-bit version of the JDK or JRE from Oracle and install it. By default it will be installed under C:\Program Files (x86)\Java. Open up a command shell and change to the top-level directory of drive. With "dir /X" you can list the shortened names of the directories. You want the shortened name of the C:\Program Files (x86) directory, or wherever the 32-bit version of the JDK or JRE was installed. You can then add some lines like the following to the StartSonar.bat batch file to put the directory containing the 32-bit version of java.exe in the beginning of the PATH:

Code Block
rem
rem Force the use of a 32-bit JDK because the file lib\wrapper.dll
rem will not load with the 64-bit version which the 64-bit OS uses
rem be default.
rem
PATH C:\PROGRA~2\Java\jdk1.6.0_23\bin;%PATH%
java -version
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.

Failed to launch the Sonar 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:

Windows Server 2003, Windows XP : C:\Windows\system32\config\systemprofile\Local Settings\Temp
Windows Server 2008, Windows 7, Windows Vista: C:\Windows\system32\config\systemprofile\AppData\Local\Temp

In most cases, the "Temp" folder is missing and should be created. See SONAR-2660.

Failed to start Sonar with Oracle due to bad USERS table structure

When another(s) USERS table exists in the Oracle DB, if the sonar user has read access on this other USERS table, the Sonar web server can't start and an exception like the following one is thrown :

Code Block
ActiveRecord::ActiveRecordError: ORA-00904: "TOTO": invalid identifier
: INSERT INTO users (login, name, email, crypted_password, salt, 
created_at, updated_at, remember_token, remember_token_expires_at, toto, id)
VALUES('admin', 'Administrator', '', 'bba4c8a0f808f9798cf8b1c153a4bb4f9178cf59', '2519754f77ea67e5d7211cd1414698f465aacebb',
TIMESTAMP'2011-06-24 22:09:14', TIMESTAMP'2011-06-24 22:09:14', null, null, null, ?)
ActiveRecord::ActiveRecordError: ORA-00904: "TOTO": invalid identifier

: INSERT INTO users (login, name, email, crypted_password, salt, 
created_at, updated_at, remember_token, remember_token_expires_at, toto, id)
VALUES('admin', 'Administrator', '', 'bba4c8a0f808f9798cf8b1c153a4bb4f9178cf59', 
'2519754f77ea67e5d7211cd1414698f465aacebb', TIMESTAMP'2011-06-24 22:09:14', TIMESTAMP'2011-06-24 22:09:14', null, null, null, ?)

See SONAR-2549.
To fix this issue, the rights of the sonar oracle user must be decreased to remove read access on the other(s) USERS table(s).

Failed to connect to update center via proxy

Double-check that settings for proxy in file sonar.properties are specified correctly.
Note that if your username contains "\" (backslash), then it should be escaped - for example username "domain\user" in file should look like:

Code Block
http.proxyUser=domain\\user

For some proxies exception "java.net.ProtocolException: Server redirected too many times" might mean incorrect username or password.

Can Sonar run in HTTPS mode

No. But you can run Sonar in a standard HTTPS infrastructure using reverse proxy (note also that URL rewriting is necessary till the following ticket is fixed: SONAR-2296).

Solaris: Issue with JRuby 1.6.6 / 1.6.7

Due to the following JRuby issue: https://jira.codehaus.org/browse/JRUBY-6494, the following line has to be added in conf/wrapper.conf:

Code Block
languagenone
wrapper.java.additional.3=-Djruby.native.enabled=false

See SONAR-4046 for more information.

Security

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.

Code Block
INSERT INTO user_roles(user_id, role) VALUES ((select id from users where login='mylogin'), 'admin');
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 :

Code Block
update users set crypted_password = '88c991e39bb88b94178123a849606905ebf440f5', salt='6522f3c5007ae910ad690bb1bdbf264a34884c6d' where login = 'admin'

This will reset the password to admin.

General

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 ?
NOSONAR

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.

SuppressWarnings

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 Sonar.

Use the switch-off plugin

http://docs.codehaus.org/display/SONAR/Switch+Off+Violations+Plugin

Switch off violation

You can use the Review feature to flag a violation as false-positive directly from the user interface.

Analyzing Source Code

Java

Source Tree Directory

The source directory tree has to match the package declarations.

For example, the following class:

Code Block
titleMyClass.java
linenumberstrue
languagejava
package com.mycompany.mypackage;
...

should be located in the following directory: [myBaseDir]/com/mycompany/mypackage/MyClass.java.

Otherwise you would get such an error while running your analysis:

Code Block
titleLog
languagenone
Exception in thread "main" org.sonar.batch.bootstrapper.BootstrapException: org.sonar.squid.api.AnalysisException: Got an exception - org.so
nar.squid.api.AnalysisException: The source directory does not correspond to the package declaration com.mycompany.mypackage, file : ..\src\MyClass.java
...

Maven analysis

...

Analysis

What is the difference between org.codehaus.mojo:sonar-maven-plugin and org.codehaus.sonar:sonar-maven-plugin?

History: org.codehaus.sonar:sonar-maven-plugin used to be an internal trick to have a Maven plugin released for each SonarQube server version while still allowing users to lock version of the org.codehaus.mojo:sonar-maven-plugin in there pom.xml.

Starting from SonarQube server 4.3 and org.codehaus.

...

mojo:sonar-maven-plugin

...

Here is the rational: Sonar needs a Maven plugin to perform analysis of your project. This plugin is part of Sonar project so the name of this plugin is :2.3, there is no more internal Maven plugin involved. So you can consider org.codehaus.sonar:sonar-maven-plugin because codehaus is hosting the project. Each time there is a new version of Sonar, there is a new version of the Sonar plugin. For a given version of the Sonar server, you MUST run the same version of the Sonar Maven plugin. It means that you would have to run

...

as deprecated and ignore it. Note that it will still be released to let people the time to migrate to org.codehaus.

...

mojo:sonar-maven-plugin:2.

...

if you have installed Sonar 2.5.
As this is very annoying to type, you could add the groupId in your settings.xml. This way you could type:

Code Block
mvn sonar:sonar

BUT in this case the latest version of the Sonar plugin would be taken. As soon as Sonar 2.6 would be released, Maven would automatically use the plugin in version 2.6. If you don't plan to upgrade your Sonar 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 add3.

Should I lock version of SonarQube Maven plugin in my pom.xml?

You can decide to lock the version of the SQ Maven plugin in your pom.xml:

Code Block
<plugin>
        <groupId>org.codehaus.sonar<mojo</groupId>
        <artifactId>sonar-maven-plugin</artifactId>
        <version>2.5<3</version>
      </plugin>

in all pom (or in corporate pom). And you would have to update your projects each time you are updating sonar server. Very annoying but that's not all.
What if you have an integration/acceptance/pre-production instance of Sonar 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 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 server release)

When you If you don't then when you run

Code Block
mvn sonar:sonar

Maven understandswill understand:

Code Block
mvn org.codehaus.mojo:sonar-maven-plugin:LATEST:sonar

. The bootstrap plugin will query Sonar server to find its version, then fork a new build to run the normal plugin with

Code Block
mvn org.codehaus.sonar:sonar:maven-plugin:XX:sonar

where XX is the version previously returned by the server. This way you can analyse the same project with different versions of Sonar and still running the same command line (except Sonar hostname of course) and without having to modify the pomand use latest release.

Most of the time you need latest version of the boostrap plugin, so no need to fix its version it in your pom, except . 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 :

Code Block
<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

    Code Block
    <mirrorOf>*,!sonar</mirrorOf>
  • 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

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 :

Code Block
<build>
  <pluginManagement>
    <plugins>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>sonar-maven-plugin</artifactId>
        <version>1.0</version>
      </plugin>
    </plugins>
  </pluginManagement>
</build>

or if you want to strictly follow Maven practices.

Cobertura 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 Systems SONAR-172.

The current workaround is to add the following lines to the pom.xml file (thanks to Wouter de Vaal):

Code Block
<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-surefire-plugin</artifactId>
   <version>2.4.3</version>
   <configuration>
      <systemProperties>
         <property>
            <name>cobertura.use.java.nio</name>
            <value>false</value>
         </property>
      </systemProperties>
   </configuration>
</plugin>

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 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 :

Code Block
MAVEN_OPTS="-Xmx512m -XX:MaxPermSize=256m"

Maven fails with a SecurityException

The message of the root exception is

...

You must also sign Sonar libraries in your Maven repository or used unsigned CGLIB library.

Maven fails with a NoClassDefFoundError

Typically error message looks like :

...

  1. Your Maven repository (local or remote) contains corrupted JARs.
  2. You have exceeded limit of open files - see see http://markmail.org/message/wvfvafgrga5b6tnd.

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.

Code Block
[INFO] Failed to resolve artifact.

No versions are present in the repository for the artifact with a range [3.0.0,3.1.0)
org.codehaus.woodstox:stax2-api:jar:null
Findbugs fails on timeout

...

INVALID HASH

While running an analysis, you may face the following error:

Code Block
[java] Timeout: killed the sub-process
...
[Fatal Error] :-1:-1: Premature end of file.

Add the findbugs-maven-plugin to the plugins section of the pom and configure the parameter "timeout".

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:

Code Block
<plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <configuration>
          <source>1.4</source>
          <target>1.4</target>
        </configuration>
      </plugin>
languagenone
12:20:22.426 INFO  - Install plugins
12:20:22.426 DEBUG - Download index of plugins
12:20:22.426 DEBUG - Download:
http://localhost:9000/deploy/plugins/index.txt (no proxy)
12:20:23.019 DEBUG - Download /deploy/plugins/xxx/sonar-xxx-plugin-X.Y.jar to C:\Documents and Settings\myUser\.sonar\cache\_tmp\1369156823019-681
...
...
INFO: EXECUTION FAILURE
...
...
ERROR: Error during Sonar runner execution
org.sonar.runner.impl.RunnerException: Unable to execute Sonar
...
...
Caused by: java.lang.IllegalStateException: INVALID HASH: File C:\Documents and Settings\myUser\.sonar\cache\_tmp\1369156823019-681 was expected to have
hash bc7b831dce659cbfa238c0d6f961409b but was downloaded with hash d41d8cd98f00b204e9800998ecf8427e
...

It means that the analyzer encountered an issue while downloading the plugins from the SonarQube server to the machine running the project analysis.

This error could be due either to:

  • A connection issue with the SonarQube 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. 
  • A corrupted local cache due to a corruption while downloading a file. Delete the local cach (or at least the failing directory) and run again the analysis.

General

Failed to analyse a project as another analysis on the same project seems to be running at the same time (SonarQube 3.4 only)

In SonarQube 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 System administrator to relaunch the project analysis with the property sonar.forceAnalysis=true. This limitation has been fixed in SonarQube 3.5 (SONAR-4053). 

How to remove false positive issues?
NOSONAR

You can use the mechanism embedded in rules engine (//NOPMD...) or the generic mechanism implemented in SonarQube: put //NOSONAR at the end of the line of the issue. This will suppress the issue.

SuppressWarnings

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 SonarQube.

Use the Switch Off Violations plugin

http://docs.codehaus.org/display/SONAR/Switch+Off+Violations+Plugin

Switch off issues

You can review an issue to flag it as false positive directly from the user interface.