Connect to the wrong Oracle schema
When having two sonarqube schemas on the same Oracle instance, especially if they are in 2 different versions, SonarQubeTM can get confused and picks the first it finds. In that case, there are two known workarounds:
1. Remove the DBA rights to the sonarqube users in Oracle
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.
Cannot connect to MySQL database
By default, remote access to MySQL database server is disabled for security reasons. If you want to remotely access to the database server from the Sonar Maven plugin, you need to follow this quick guide.
Failed to start on 64-bit Windows 7
If you have installed a 64-bit version of the JDK or JRE, and Windows is using the 64-bit version by default, then the batch file windows-x86-32\StartSonar.bat will not start the server because the wrapper.exe program called by the batch file cannot load the lib\wrapper.dll library. You can check which version of Java is being used by opening a shell and typing "java -version". If it is a 64-bit version you will see something like "Java HotSpot (TM) 64-Bit Server VM" in the description. You can download a 32-bit version of the JDK or JRE from Oracle and install it. By default it will be installed under C:\Program Files (x86)\Java. Open up a command shell and change to the top-level directory of drive. With "dir /X" you can list the shortened names of the directories. You want the shortened name of the C:\Program Files (x86) directory, or wherever the 32-bit version of the JDK or JRE was installed. You can then add some lines like the following to the StartSonar.bat batch file to put the directory containing the 32-bit version of java.exe in the beginning of the PATH:
rem rem Force the use of a 32-bit JDK because the file lib\wrapper.dll rem will not load with the 64-bit version which the 64-bit OS uses rem be default. rem PATH C:\PROGRA~2\Java\jdk1.6.0_23\bin;%PATH% java -version
Failed to start on Windows Vista
SonarQubeTM seems unable to start when installed under the folder "Program Files" in VISTA. It should therefore not be installed there.
Failed to launch the SonarQubeTM service on Windows platform with a LocalSystem account
This error happens when the temporary file path specified for the Local System doesn't exist. Assuming that environment variables have their default settings and that Windows is installed on the ‘C’ drive, the following paths should exist:
Windows Server 2003, Windows XP : C:\Windows\system32\config\systemprofile\Local Settings\Temp
Windows Server 2008, Windows 7, Windows Vista: C:\Windows\system32\config\systemprofile\AppData\Local\Temp
In most cases, the "Temp" folder is missing and should be created. See SONAR-2660.
Failed to start SonarQubeTM with Oracle due to bad USERS table structure
When another(s) USERS table exists in the Oracle DB, if the sonarqube user has read access on this other USERS table, the SonarQubeTM web server can't start and an exception like the following one is thrown:
ActiveRecord::ActiveRecordError: ORA-00904: "TOTO": invalid identifier : INSERT INTO users (login, name, email, crypted_password, salt, created_at, updated_at, remember_token, remember_token_expires_at, toto, id) VALUES('admin', 'Administrator', '', 'bba4c8a0f808f9798cf8b1c153a4bb4f9178cf59', '2519754f77ea67e5d7211cd1414698f465aacebb', TIMESTAMP'2011-06-24 22:09:14', TIMESTAMP'2011-06-24 22:09:14', null, null, null, ?) ActiveRecord::ActiveRecordError: ORA-00904: "TOTO": invalid identifier : INSERT INTO users (login, name, email, crypted_password, salt, created_at, updated_at, remember_token, remember_token_expires_at, toto, id) VALUES('admin', 'Administrator', '', 'bba4c8a0f808f9798cf8b1c153a4bb4f9178cf59', '2519754f77ea67e5d7211cd1414698f465aacebb', TIMESTAMP'2011-06-24 22:09:14', TIMESTAMP'2011-06-24 22:09:14', null, null, null, ?)
To fix this issue, the rights of the sonarqube Oracle user must be decreased to remove read access on the other(s) USERS table(s).
Failed to connect to update center via proxy
Double-check that settings for proxy in file
sonar.properties are specified correctly.
Note that if your username contains "\" (backslash), then it should be escaped - for example username "domain\user" in file should look like:
For some proxies exception "java.net.ProtocolException: Server redirected too many times" might mean incorrect username or password.
Can SonarQubeTM run in HTTPS mode
No. But you can run SonarQubeTM 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 SonarQubeTM server will fall back on HTTP).
Solaris: Issue with JRuby 1.6.6+ (should be fixed with JRuby 1.7.0)
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).
What is the difference between What is the difference between org.codehaus.mojo:sonar-maven-plugin and org.codehaus.sonar:sonar-maven-plugin?
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
Here is the rational: SonarQubeTM needs a Maven plugin to perform analysis of your project. This plugin is part of SonarQubeTM project so the name of this plugin is :2.3, there is no more internal Maven plugin involved. So you can consider org.codehaus.sonar:sonar-maven-plugin because codehaus is hosting the project. Each time there is a new version of SonarQubeTM, there is a new version of the Sonar Maven plugin. For a given version of the SonarQubeTM server, you MUST run the same version of the Sonar Maven plugin. It means that you would have to run:
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 SonarQubeTM 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 Maven Sonar plugin would be taken. As soon as SonarQubeTM 2.6 would be released, Maven would automatically use the plugin in version 2.6. If you don't plan to upgrade your SonarQubeTM 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:
<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 SonarQubeTM server. Very annoying but that's not all.
What if you have an integration/acceptance/pre-production instance of SonarQubeTM 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 SonarQubeTM server release)
When you If you don't then when you run
Maven understandswill understand:
. The bootstrap plugin will query SonarQubeTM 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 analyze the same project with different versions of SonarQubeTM and still running the same command line (except SonarQubeTM 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) .
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</version> </plugin> </plugins> </pluginManagement> </build>
or if you want to strictly follow Maven practices.
Cobertura exception on Linux System while accessing the cobertura.ser file
It means that the analyzer encountered an issue while downloading the plugins from the SonarQube TM server to the machine running the project analysis.
- A connection issue with the SonarQube TM 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.
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 TM 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 'property
sonar.forceAnalysis=true'. This limitation has been fixed in SonarQube TM 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?
You can use the mechanism embedded in rules engine (//NOPMD...) or the generic mechanism implemented in SonarQubeTM: 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 SonarQubeTM.
Use the Switch Off Violations plugin