When having two sonarqube schemas on the same Oracle instance, especially if they are in 2 different versions, SonarQubecan SonarQube 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.
SonarQube seems unable to start when installed under the folder "Program Files" in VISTA. It should therefore not be installed there.
Failed to launch the SonarQubeservice SonarQube service on Windows platform with a LocalSystem account
In most cases, the "Temp" folder is missing and should be created. See SONAR-2660.
Failed to start SonarQubewith SonarQube with Oracle due to bad USERS table structure
For some proxies exception "java.net.ProtocolException: Server redirected too many times" might mean incorrect username or password.
Can SonarQuberun SonarQube run in HTTPS mode
No. But you can run SonarQubein SonarQube 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 SonarQube 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 org.codehaus.mojo:sonar-maven-plugin and org.codehaus.sonar:sonar-maven-plugin?
Here is the rational: SonarQubeneeds SonarQube needs a Maven plugin to perform analysis of your project. This plugin is part of SonarQubeproject SonarQube 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 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:
if you have installed SonarQube2SonarQube 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 SonarQube2SonarQube 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 add:
in all pom (or in corporate pom). And you would have to update your projects each time you are updating SonarQubeserverSonarQube 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.
- 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 SonarQubeserver SonarQube server release)
When you run
It means that the analyzer encountered an issue while downloading the plugins from the SonarQubeserver SonarQube server to the machine running the project analysis.
- A connection issue with the SonarQubeserverSonarQube 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.
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 SonarQube3SonarQube 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).