SonarQube with Jacoco (with Gradle ) execution fails [duplicate] - gradle

I recently tried to upgrade my Gradle build to SonarQube plugin 2.2 and encountered the following error:
Caused by: java.lang.IllegalStateException: No files nor directories matching '[/opt/bamboo-home/xml-data/build-dir/SPR-SONAR-JOB1/spring-core/build/libs/spring-cglib-repack-3.2.4.jar' in directory /opt/bamboo-home/xml-data/build-dir/SPR-SONAR-JOB1/spring-aop
org.sonar.batch.scan.ProjectReactorBuilder.validateDirectories(ProjectReactorBuilder.java:302)
org.sonar.batch.scan.ProjectReactorBuilder.loadChildProject(ProjectReactorBuilder.java:217)
org.sonar.batch.scan.ProjectReactorBuilder.defineChildren(ProjectReactorBuilder.java:192)
org.sonar.batch.scan.ProjectReactorBuilder.execute(ProjectReactorBuilder.java:116)
org.sonar.batch.scan.ProjectScanContainer.projectBootstrap(ProjectScanContainer.java:120)
org.sonar.batch.scan.ProjectScanContainer.doBeforeStart(ProjectScanContainer.java:98)
org.sonar.api.platform.ComponentContainer.startComponents(ComponentContainer.java:91)
org.sonar.api.platform.ComponentContainer.execute(ComponentContainer.java:78)
org.sonar.batch.scan.ScanTask.scan(ScanTask.java:64)
org.sonar.batch.scan.ScanTask.execute(ScanTask.java:51)
org.sonar.batch.bootstrap.TaskContainer.doAfterStart(TaskContainer.java:125)
org.sonar.api.platform.ComponentContainer.startComponents(ComponentContainer.java:93)
org.sonar.api.platform.ComponentContainer.execute(ComponentContainer.java:78)
org.sonar.batch.bootstrap.BootstrapContainer.executeTask(BootstrapContainer.java:173)
org.sonar.batch.bootstrapper.Batch.executeTask(Batch.java:95)
org.sonar.batch.bootstrapper.Batch.execute(Batch.java:67)
org.sonarsource.scanner.api.internal.batch.BatchIsolatedLauncher.executeOldVersion(BatchIsolatedLauncher.java:70)
org.sonarsource.scanner.api.internal.IsolatedLauncherProxy.invoke(IsolatedLauncherProxy.java:60)
com.sun.proxy.$Proxy77.executeOldVersion(Unknown Source)
org.sonarsource.scanner.api.EmbeddedScanner.doExecute(EmbeddedScanner.java:238)
org.sonarsource.scanner.api.EmbeddedScanner.runAnalysis(EmbeddedScanner.java:151)
org.sonarqube.gradle.SonarQubeTask.run(SonarQubeTask.java:93)
This spring-cglib-repack-3.2.4.jar does exist in the spring-core/build/libs/ folder, since my build is repackaging the cglib dependency in a custom jarjar task.
It seems the plugin is looking for that resource under the spring-aop folder, hence the exception.
Note that the same configuration works with the 2.1 version.

I had to put path to the class files
sonar.java.binaries=target/
sonar-project.properties
Sonar version 6.2

A pull request was submitted to fix this issue. I have created a ticket and will release a bugfix:
https://jira.sonarsource.com/browse/SONARGRADL-30

Related

m2e shows error in execution for jaxb2-maven-plugin schemagen goal

I am using maven and the jaxb2-maven-plugin version 2.2 to generate the xsd by calling the goal schemagen.
Everything works find both when I run maven from the command line or when I run it within eclipse using m2e. So far so good.
Unfortunately, in eclipse an error/exception in the pom file is shown:
Execution serviceConfigs-schemagen of goal org.codehaus.mojo:jaxb2-maven-plugin:2.2:schemagen failed. (org.codehaus.mojo:jaxb2-maven-plugin:2.2:schemagen:serviceConfigs-schemagen:generate-resources)
org.apache.maven.plugin.PluginExecutionException: Execution serviceConfigs-schemagen of goal org.codehaus.mojo:jaxb2-maven-plugin:2.2:schemagen failed.
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
at org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:331)
at org.eclipse.m2e.core.internal.embedder.MavenImpl$11.call(MavenImpl.java:1362)
at org.eclipse.m2e.core.internal.embedder.MavenImpl$11.call(MavenImpl.java:1)
at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:177)
at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:112)
at org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:1360)
at org.eclipse.m2e.core.project.configurator.MojoExecutionBuildParticipant.build(MojoExecutionBuildParticipant.java:52)
at org.eclipse.m2e.core.internal.builder.MavenBuilderImpl.build(MavenBuilderImpl.java:137)
at org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:172)
at org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:1)
at org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod$1$1.call(MavenBuilder.java:115)
at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:177)
at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:112)
at org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod$1.call(MavenBuilder.java:105)
at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:177)
at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:151)
at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:99)
at org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.execute(MavenBuilder.java:86)
at org.eclipse.m2e.core.internal.builder.MavenBuilder.build(MavenBuilder.java:200)
at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:735)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246)
at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:301)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:304)
at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:360)
at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:383)
at org.eclipse.core.internal.resources.Workspace.buildInternal(Workspace.java:487)
at org.eclipse.core.internal.resources.Workspace.build(Workspace.java:406)
at org.eclipse.ui.actions.BuildAction$1.runInWorkspace(BuildAction.java:285)
at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:39)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)
Caused by: java.lang.NullPointerException
at org.codehaus.mojo.jaxb2.shared.environment.ToolExecutionEnvironment.restore(ToolExecutionEnvironment.java:182)
at org.codehaus.mojo.jaxb2.schemageneration.AbstractXsdGeneratorMojo.performExecution(AbstractXsdGeneratorMojo.java:528)
at org.codehaus.mojo.jaxb2.AbstractJaxbMojo.execute(AbstractJaxbMojo.java:257)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
... 33 more
If I perform a Maven --> Update Project the error disappears for a while, however as soon as i build the project it appears again.
Does somebody knows how to get rip or this error message?
Thanks in advance
Javi
Seems it was realted to a bug in that version of the plugin. Updating the plugin to version 2.4 has solved the issue for me.

Unable to run Sonar with Hybris

I am new to SonarQube and trying to run the analytics on all the extensions in one go. I am able to run it successfully for extensions individually but when I run "ant sonar" with hybris, it gives me below exception:
[echo] - sonar.jdbc.url : ${sonar.jdbc.url}
[echo] - sonar.projectName : Superproject
[echo] - sonar.project.key : superprojectkey
[echo] - sonar.project.version : 1.0
[echo] - sonar.excludedExtensions :
[echo] - sonar.language : java
[echo] *************************************************
[echo]
r:sonar] Apache Ant(TM) version 1.9.1 compiled on May 15 2013
r:sonar] Sonar Ant Task version: 2.1
r:sonar] Loaded from: file:/E:/hybris/bin/platform/resources/ant
r:sonar] INFO: Default locale: "en_IN", source code encoding: "UTF-8"
r:sonar] INFO: Work directory: E:\hybris\bin\platform\.sonar
r:sonar] ERROR: Sonar server 'http://localhost:9000' can not be reached
E:\\hybris\bin\platform\resources\ant\sonar.xml:84: org.sonar.runner.kevinsawicki.Ht
at org.sonar.runner.kevinsawicki.HttpRequest.code(HttpRequest.java:1392)
at org.sonar.runner.kevinsawicki.HttpRequest.ok(HttpRequest.java:1417)
at org.sonar.runner.impl.ServerConnection.downloadString(ServerConnection.java:83)
at org.sonar.runner.impl.ServerVersion.downloadVersion(ServerVersion.java:49)
at org.sonar.runner.impl.ServerVersion.version(ServerVersion.java:40)
at org.sonar.runner.impl.ServerVersion.is35Compatible(ServerVersion.java:64)
at org.sonar.runner.impl.JarDownloader.download(JarDownloader.java:39)
at org.sonar.runner.impl.BatchLauncher$1.run(BatchLauncher.java:59)
at java.security.AccessController.doPrivileged(Native Method)
at org.sonar.runner.impl.BatchLauncher.doExecute(BatchLauncher.java:57)
at org.sonar.runner.impl.BatchLauncher.execute(BatchLauncher.java:50)
at org.sonar.runner.api.EmbeddedRunner.doExecute(EmbeddedRunner.java:71)
at org.sonar.runner.api.Runner.execute(Runner.java:89)
at org.sonar.ant.SonarTask.launchAnalysis(SonarTask.java:53)
at org.sonar.ant.SonarTask.execute(SonarTask.java:48)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:68)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.taskdefs.MacroInstance.execute(MacroInstance.java:396)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:435)
at org.apache.tools.ant.Target.performTasks(Target.java:456)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1393)
at org.apache.tools.ant.Project.executeTarget(Project.java:1364)
at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1248)
at org.apache.tools.ant.Main.runBuild(Main.java:851)
at org.apache.tools.ant.Main.startAnt(Main.java:235)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)
Caused by: java.net.ConnectException: Connection refused: connect
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at sun.net.www.protocol.http.HttpURLConnection$10.run(HttpURLConnection.java:1890)
at sun.net.www.protocol.http.HttpURLConnection$10.run(HttpURLConnection.java:1885)
at java.security.AccessController.doPrivileged(Native Method)
at sun.net.www.protocol.http.HttpURLConnection.getChainedException(HttpURLConnection.java:1884)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1457)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1441)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480)
at org.sonar.runner.kevinsawicki.HttpRequest.code(HttpRequest.java:1390)
... 44 more
I know this is an configuration issue but I could not locate the file where the LOG is saying it is.
Also, why is it requiring jdbc url?
Thanks.
i just write down the approach we are using within our projects - not exactly as we are wrapping ant with gradle but how we proceed and configure everything.
We are not using the ant sonar scanner but either, the gradle sonar scanner [1] or the jenkins sonar scanner [2], so in this case you could actually use the sonar scanner [3].
Configuring sonar properties:
you can easily put all your configurations in your project root in a file called sonar-project.properties.
sonar.host.url=<sonar url>
sonar.projectKey=<project key>
sonar.projectName=<project name>
# you could use here java as language, but if you also want to analyse JS and other languages remove it, and adapt the source path to add those too
sonar.language=java
sonar.sources=<path-to-extension>/src,\
<path-to-extension>/hmc/src,\
<path-to-extension>/web/src,\
sonar.tests=<path-to-extension>/testsrc
sonar.java.binaries=**/classes
sonar.java.libraries=**/*.jar
sonar.java.test.binaries=**/classes
sonar.java.test.libraries=**/*.jar
this is just a simple basic configuration - so you need to define your test plugin and paths in here too.
i added paths for web and hmc, if your extension is not using them remove them
i just added one extensions, you could simply extend it with multiple ones
every config you do, you can simply put into this sonar-project.properties, and you can even check it into your VCS, to share it with others.
benefits are that this settings are connected with your source, so if you have a new extension you also adapt the sonar settings, and do not need to adapt any build etc.
Running the scanner
now you can simple use every runner you like by using those project properties. either jenkins, or gradle or local, you just need to ensure that the sonar-project.properties file is in the root of your project, and pointing to the right files.
Acknowledge
i know this is not the default hybris way, and it is not using the ant target of hybris, but i figured out, that this approach gives me much more flexibility than the default way!
[1] https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner+for+Gradle?src=contextnavpagetreemode
[2] https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner+for+Jenkins
[3] https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner
are you sure that the Sonarqube server is launched? Maybe launch it manually and be sure that is is visible in your browser when accessing locallhost:9000/about .
As the root problem is the sonarserver not being available i'd go for that...
The Sonar Host URL is configured through a property called sonar.host.url
On the project I was working a while ago this property was set in hybris\config\local.properties
Related to the INFO: Work directory: E:\hybris\bin\platform.sonar logged,
I think that the working directory can be set using the sonar.working.directory which ,if not set, is somehow computed to be the one you saw in logs (i.e hybris\bin\platform.sonar)

"IllegalStateException: No files nor directories matching" for non-existing JAR

I recently tried to upgrade my Gradle build to SonarQube plugin 2.2 and encountered the following error:
Caused by: java.lang.IllegalStateException: No files nor directories matching '[/opt/bamboo-home/xml-data/build-dir/SPR-SONAR-JOB1/spring-core/build/libs/spring-cglib-repack-3.2.4.jar' in directory /opt/bamboo-home/xml-data/build-dir/SPR-SONAR-JOB1/spring-aop
org.sonar.batch.scan.ProjectReactorBuilder.validateDirectories(ProjectReactorBuilder.java:302)
org.sonar.batch.scan.ProjectReactorBuilder.loadChildProject(ProjectReactorBuilder.java:217)
org.sonar.batch.scan.ProjectReactorBuilder.defineChildren(ProjectReactorBuilder.java:192)
org.sonar.batch.scan.ProjectReactorBuilder.execute(ProjectReactorBuilder.java:116)
org.sonar.batch.scan.ProjectScanContainer.projectBootstrap(ProjectScanContainer.java:120)
org.sonar.batch.scan.ProjectScanContainer.doBeforeStart(ProjectScanContainer.java:98)
org.sonar.api.platform.ComponentContainer.startComponents(ComponentContainer.java:91)
org.sonar.api.platform.ComponentContainer.execute(ComponentContainer.java:78)
org.sonar.batch.scan.ScanTask.scan(ScanTask.java:64)
org.sonar.batch.scan.ScanTask.execute(ScanTask.java:51)
org.sonar.batch.bootstrap.TaskContainer.doAfterStart(TaskContainer.java:125)
org.sonar.api.platform.ComponentContainer.startComponents(ComponentContainer.java:93)
org.sonar.api.platform.ComponentContainer.execute(ComponentContainer.java:78)
org.sonar.batch.bootstrap.BootstrapContainer.executeTask(BootstrapContainer.java:173)
org.sonar.batch.bootstrapper.Batch.executeTask(Batch.java:95)
org.sonar.batch.bootstrapper.Batch.execute(Batch.java:67)
org.sonarsource.scanner.api.internal.batch.BatchIsolatedLauncher.executeOldVersion(BatchIsolatedLauncher.java:70)
org.sonarsource.scanner.api.internal.IsolatedLauncherProxy.invoke(IsolatedLauncherProxy.java:60)
com.sun.proxy.$Proxy77.executeOldVersion(Unknown Source)
org.sonarsource.scanner.api.EmbeddedScanner.doExecute(EmbeddedScanner.java:238)
org.sonarsource.scanner.api.EmbeddedScanner.runAnalysis(EmbeddedScanner.java:151)
org.sonarqube.gradle.SonarQubeTask.run(SonarQubeTask.java:93)
This spring-cglib-repack-3.2.4.jar does exist in the spring-core/build/libs/ folder, since my build is repackaging the cglib dependency in a custom jarjar task.
It seems the plugin is looking for that resource under the spring-aop folder, hence the exception.
Note that the same configuration works with the 2.1 version.
I had to put path to the class files
sonar.java.binaries=target/
sonar-project.properties
Sonar version 6.2
A pull request was submitted to fix this issue. I have created a ticket and will release a bugfix:
https://jira.sonarsource.com/browse/SONARGRADL-30

SonarQube 5.1.2 fails to recognize relative path for sonar.sources

Below is my directory structure for SonarQube analysis.
I was using SonarQube 5.0 with C++ Community plugin version 0.9.4 and sonar-runner 2.4 with sonar.sources=../CheckoutDir1 mentioned in sonar-project.properties file. This was working like a charm.
Then I upgraded to SonarQube 5.1.2, keeping the C++ Community plugin, sonar-runner and sonar-project.properties file intact. Now sonar-runner fails with the following error:
14:18:17.531 INFO - Base dir: D:\CheckoutDir2
14:18:17.531 INFO - Working dir: D:\CheckoutDir2\.sonar
14:18:17.531 INFO - Source paths: ../CheckoutDir1
.
.
.
.
ERROR: Error during Sonar runner execution
org.sonar.runner.impl.RunnerException: Unable to execute Sonar
at org.sonar.runner.impl.BatchLauncher$1.delegateExecution(BatchLauncher.java:91)
at org.sonar.runner.impl.BatchLauncher$1.run(BatchLauncher.java:75)
at java.security.AccessController.doPrivileged(Native Method)
at org.sonar.runner.impl.BatchLauncher.doExecute(BatchLauncher.java:69)
at org.sonar.runner.impl.BatchLauncher.execute(BatchLauncher.java:50)
at org.sonar.runner.api.EmbeddedRunner.doExecute(EmbeddedRunner.java:102)
at org.sonar.runner.api.Runner.execute(Runner.java:100)
at org.sonar.runner.Main.executeTask(Main.java:70)
at org.sonar.runner.Main.execute(Main.java:59)
at org.sonar.runner.Main.main(Main.java:53)
Caused by: java.lang.NullPointerException
at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:98)
at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
at sun.nio.fs.WindowsPath.parse(WindowsPath.java:94)
at sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:255)
at sun.nio.fs.AbstractPath.resolve(AbstractPath.java:53)
at org.sonar.api.batch.fs.internal.DefaultInputFile.path(DefaultInputFile.java:72)
at org.sonar.api.batch.fs.internal.DefaultInputFile.file(DefaultInputFile.java:64)
at org.sonar.api.batch.fs.internal.PathPattern$RelativePathPattern.match(PathPattern.java:101)
at org.sonar.batch.scan.filesystem.LanguageDetection.isCandidateForLanguage(LanguageDetection.java:124)
at org.sonar.batch.scan.filesystem.LanguageDetection.language(LanguageDetection.java:97)
at org.sonar.batch.scan.filesystem.InputFileBuilder.completeAndComputeMetadata(InputFileBuilder.java:100)
at org.sonar.batch.scan.filesystem.FileIndexer$1.call(FileIndexer.java:157)
at org.sonar.batch.scan.filesystem.FileIndexer$1.call(FileIndexer.java:154)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
Strangely, the debug parameters -X, -e, -Dsonar.verbose=true in sonar-runner revealed no other information except java.lang.NullPointerException.
If I mention the absolute path for sonar.sources, the SonarQube analysis works fine.
Please suggest how to resolve this problem? Also, SonarQube 5.1.2 should clearly print the debug logs about not being able to locate the sonar.sources from a relative path.
As I can see in the log that sonar is considering CheckoutDir2 as your base dir,
Which is not correct,
you should set sonar.projectBaseDir=<AbsolutePath>/ProjectName/CheckoutDir1 and then sonar.sources=.
so now even if sonar-project.properties file is not in the same directory as the source code, it will still work as if it was.

SonarQube Nullpointer on analysis, missing fields or rules parameters

I'm running into a nullpointer exception when running analysis on a java project.
The condition that triggers the analysis failure only happens when I activate certain Rules in the Quality Profile. Particularly, any rule that has a parameter you can override, causes the nullpointer failure. It fails whether or not I provide an override value or if the parameter is left default.
I should note that I can get successful analysis to complete if those particular rules are deactivated in the quality profile. It only seems to be related to certain rules that have parameters.
I can replicate this Nullpointer failure with both the sonar-runner, and the org.sonarqube gradle plugin (v 1.0). So I suspect it is not a problem with the runner or the plugin but some kind of setup issue with the SonarQube server and/or database.
The problem is, I don't know how to go in and fix this issue. The SonarQube database isn't documented (that I'm aware) I suspect that there is something maybe missing in the database but I'm not even sure where they might be.
Any suggestions on where I might look?
Versions:
SonarQube 4.5.2
SonarQube Runner 2.4
Java 1.8.0_40 Oracle Corporation (64-bit)
Mac OS X 10.10.4 x86_64
Here is the stack trace of the error:
INFO: ------------------------------------------------------------------------
INFO: EXECUTION FAILURE
INFO: ------------------------------------------------------------------------
Total time: 1:43.316s
Final Memory: 27M/635M
INFO: ------------------------------------------------------------------------
ERROR: Error during Sonar runner execution
org.sonar.runner.impl.RunnerException: Unable to execute Sonar
at org.sonar.runner.impl.BatchLauncher$1.delegateExecution(BatchLauncher.java:91)
at org.sonar.runner.impl.BatchLauncher$1.run(BatchLauncher.java:75)
at java.security.AccessController.doPrivileged(Native Method)
at org.sonar.runner.impl.BatchLauncher.doExecute(BatchLauncher.java:69)
at org.sonar.runner.impl.BatchLauncher.execute(BatchLauncher.java:50)
at org.sonar.runner.api.EmbeddedRunner.doExecute(EmbeddedRunner.java:102)
at org.sonar.runner.api.Runner.execute(Runner.java:100)
at org.sonar.runner.Main.executeTask(Main.java:70)
at org.sonar.runner.Main.execute(Main.java:59)
at org.sonar.runner.Main.main(Main.java:53)
Caused by: java.lang.NullPointerException
at org.sonar.api.batch.rule.Checks.getField(Checks.java:180)
at org.sonar.api.batch.rule.Checks.configureFields(Checks.java:167)
at org.sonar.api.batch.rule.Checks.instantiate(Checks.java:152)
at org.sonar.api.batch.rule.Checks.addAnnotatedChecks(Checks.java:127)
at org.sonar.java.SonarComponents.registerTestCheckClasses(SonarComponents.java:128)
at org.sonar.plugins.java.JavaSquidSensor.analyse(JavaSquidSensor.java:82)
at org.sonar.batch.phases.SensorsExecutor.executeSensor(SensorsExecutor.java:79)
at org.sonar.batch.phases.SensorsExecutor.execute(SensorsExecutor.java:70)
at org.sonar.batch.phases.PhaseExecutor.execute(PhaseExecutor.java:119)
at org.sonar.batch.scan.ModuleScanContainer.doAfterStart(ModuleScanContainer.java:194)
at org.sonar.api.platform.ComponentContainer.startComponents(ComponentContainer.java:93)
at org.sonar.api.platform.ComponentContainer.execute(ComponentContainer.java:78)
at org.sonar.batch.scan.ProjectScanContainer.scan(ProjectScanContainer.java:233)
at org.sonar.batch.scan.ProjectScanContainer.scanRecursively(ProjectScanContainer.java:228)
at org.sonar.batch.scan.ProjectScanContainer.doAfterStart(ProjectScanContainer.java:221)
at org.sonar.api.platform.ComponentContainer.startComponents(ComponentContainer.java:93)
at org.sonar.api.platform.ComponentContainer.execute(ComponentContainer.java:78)
at org.sonar.batch.scan.ScanTask.scan(ScanTask.java:64)
at org.sonar.batch.scan.ScanTask.execute(ScanTask.java:51)
at org.sonar.batch.bootstrap.TaskContainer.doAfterStart(TaskContainer.java:125)
at org.sonar.api.platform.ComponentContainer.startComponents(ComponentContainer.java:93)
at org.sonar.api.platform.ComponentContainer.execute(ComponentContainer.java:78)
at org.sonar.batch.bootstrap.BootstrapContainer.executeTask(BootstrapContainer.java:173)
at org.sonar.batch.bootstrapper.Batch.executeTask(Batch.java:95)
at org.sonar.batch.bootstrapper.Batch.execute(Batch.java:67)
at org.sonar.runner.batch.IsolatedLauncher.execute(IsolatedLauncher.java:48)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.sonar.runner.impl.BatchLauncher$1.delegateExecution(BatchLauncher.java:87)
... 9 more
We solved the problem, and the problem was indeed the Java plugin on the SonarQube server. The solution was to downgrade the Java plugin though. Here are the versions we ended up using:
Checkstyle [checkstyle] 2.2 Analyze Java code with Checkstyle.
Clover [clover] 3.0 Get code coverage with Atlassian Clover.
Cobertura [cobertura] 1.6.3 Get code coverage with Cobertura.
Findbugs [findbugs] 3.1 Analyze Java code with Findbugs 3.0.0.
Java [java] 2.9.1 SonarQube rule engine.
JIRA [jira] 1.2 Connects SonarQube to Atlassian JIRA in various ways.
LDAP [ldap] 1.4 Delegates authentication to LDAP.
PMD [pmd] 2.3 Analyze Java code with PMD.

Resources