Connect to the wrong Oracle schema
When having 2 Sonar schema 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 work around workarounds:
1. Remove the DBA rights to the Sonar users in oracleOracle
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.
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 (in this case the reverse proxy must be configured to set the value 'X_FORWARDED_PROTO: https' in each HTTP request header. Without this property, redirection initiated by the Sonar server will fall back on HTTP).
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:
See SONAR-4046 for more information.
Note that this property has to be set when launching Tomcat (as the wrapper.conf file is not used when deploying in application server).
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.
This will reset the password to admin.
I am not getting expected new violations in the differential views of drill-down ?
3 reasons can explain this :
Failed to analyse a project as another analysis on the same project seems to be running at the same time (Sonar 3.4 only)
In Sonar 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 Sonar administrator to relaunch the project analysis with the property 'sonar.forceAnalysis=true'. This limitation has been fixed in Sonar 3.5 (SONAR-4053).
How to remove false-positive violations?
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.
Switch Off Violations plugin
You can use the Review feature to flag a violation as false-positive directly from the user interface.
What is the difference between org.codehaus.mojo:sonar-maven-plugin and org.codehaus.sonar:sonar-maven-plugin?
Here is the rational: Sonar need a Maven plugin to perform analysis of your project. This plugin is part of Sonar 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 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
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:
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 add:
<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 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 run
. The bootstrap plugin will query Sonar server to find its version, then fork a new build to run the normal plugin with
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 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).
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 :
<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
- 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 :
<build> <pluginManagement> <plugins> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>sonar-maven-plugin</artifactId> <version>1.0-beta-2</version> </plugin> </plugins> </pluginManagement> </build>
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) :
<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 :
Maven fails with a SecurityException
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.
Maven fails with a NoClassDefFoundError
Typically error message looks like :
Possible explanations of such problem :
- Your Maven repository (local or remote) contains corrupted JARs.
- 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.
[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
See SONAR-1439. Findbugs fails with the following logs :
[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".
Java heap space whilst running CpdSensor
Running CPD to find copy paste of source is a memory hungry process and requires sometimes too much resources on very big projects. It is therefore possible to skip copy paste detection by going to configuration -> settings -> Duplications
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:
<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.4</source> <target>1.4</target> </configuration> </plugin>