Message-ID: <2079779356.529.1417148928899.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_528_1983418870.1417148928898" ------=_Part_528_1983418870.1417148928898 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
History: org.codehaus.sonar:sonar-maven-plugin used to = be an internal trick to have a Maven plugin released for each SonarQube ser= ver 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 peo= ple the time to migrate to org.codehaus.mojo:sonar-maven-p= lugin:2.3.
You can decide to lock the version of the SQ Maven plugin in your pom.xm= l:
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 fi= x it in your pom. Except if you want to test a particular version (an old o= ne or a SNAPSHOT for example) or if you want to strictly follow Maven pract= ices.
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):
If you get this error message after launching the maven command line &qu= ot;mvn sonar:sonar" add the "-U" parameter to the command li= ne. 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 ce= rtainly encountered Maven bug MNG-4001. The onl= y known workaround is to delete the org\codehaus\mojo directory in your loc= al Maven repository. Of course, if your local Maven repository is synchroni= zed 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
The CGLIB library available in your Maven repository is certainly signed= which is not the case on IBIBLIO repository. Perhaps you or your Maven adm= inistrator have signed this jar to include it into a Java Web Start applica= tion. Unfortunately signing CGLIB jar file breaks Hibernate's use of CGLIB,= as it generates proxy classes in the same package (org.sonar.commons.datab= ase.* 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.SecurityEx= ception.
You must also sign Sonar libraries in your Maven repository or used unsi= gned CGLIB library.
Typically error message looks like :
Possible explanations of such problem :
You have to add the parameter -Denforcer.skip=3Dtrue to the Maven comman= d-line.
The following error occurs when using Maven Archiva 1.1. It must be upgr= aded to 1.2.1.
While running an analysis, you may face the following error:
It means that the analyzer encountered an issue while downloading the pl= ugins 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 semaph=
ore mechanism has been introduced to prevent launching several analysi=
s 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 relau=
nch the project analysis with the property
=3Dtrue. 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 g= eneric 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(&qu= ot;all") has been added to SonarQube.
You can review an issue to flag it as false positive directly from the u= ser interface.