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:2.3, there is no more internal Maven plugin involved. So you can consider org.codehaus.sonar:sonar-maven-plugin 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.3.
You can decide to lock the version of the SQ Maven plugin in your pom.xml:
<plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>sonar-maven-plugin</artifactId> <version>2.3</version> </plugin>
If you don't then when you run
Maven will understand:
and use latest release.
Most of the time you need latest version of the plugin, so no need to fix it in your pom. Except if you want to test a particular version (an old one or a SNAPSHOT for example) or if you want to strictly follow Maven practices.
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):
<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>
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.
Increase the maven available memory by setting the environment variable :
The message of the root exception is
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.
Typically error message looks like :
Possible explanations of such problem :
You have to add the parameter -Denforcer.skip=true to the Maven command-line.
The following error occurs when using Maven Archiva 1.1. It must be upgraded to 1.2.1.
[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
While running an analysis, you may face the following error:
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:
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).
Currently, the only way to force a reindex is to:
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.
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.
You can review an issue to flag it as false positive directly from the user interface.