Versions Compared

Key

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

Analysis

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

Here is the rational: SonarQube needs a Maven plugin to perform analysis of your project. This plugin is part of SonarQube 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 SonarQube, there is a new version of the Sonar Maven plugin. For a given version of the SonarQube server, you MUST run the same version of the Sonar Maven plugin. It means that you would have to run:

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

if you have installed SonarQube 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 Maven Sonar plugin would be taken. As soon as SonarQube 2.6 would be released, Maven would automatically use the plugin in version 2.6. If you don't plan to upgrade your SonarQube 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:

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

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

When you run

Code Block
mvn sonar:sonar

Maven understands:

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

. The bootstrap plugin will query SonarQube 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 analyze the same project with different versions of SonarQube and still running the same command line (except SonarQube 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).

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

Code Block
class "org.sonar.commons.database.SchemaInfo$$EnhancerByCGLIB$$15d095d4"'s signer information does not match
signer information of other classes in the same package

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 with a NoClassDefFoundError

Typically error message looks like :

No Format
java.lang.NoClassDefFoundError: org/apache/commons/configuration/Configuration

Possible explanations of such problem :

  1. Your Maven repository (local or remote) contains corrupted JARs.
  2. You have exceeded limit of open files - 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

INVALID HASH

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

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

...

frameborder0
height10
srchttp://redirect.sonarsource.com/doc/faq.html

Documentation has been moved to http://redirect.sonarsource.com/doc/faq.html.

Documentation has been moved to http://redirect.sonarsource.com/doc/faq.html.