Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

...

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

...

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 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 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 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 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 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) or if you want to strictly follow Maven practices.

Cobertura exception on Linux System while accessing the cobertura.ser file

...

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 trigger a full SonarQube ES reindex?

Currently, the only way to force a reindex is to:

  • Stop your server
  • Remove the contents of the $SQ_HOME/data/es directory
  • Start your server
How to remove false positive issues?

...