[GRADLE-3062] Update Sonar Runner to 2.3 Created: 04/Apr/14  Updated: 05/Jan/15  Resolved: 02/Sep/14

Status: Resolved
Project: Gradle
Affects Version/s: 1.11
Fix Version/s: 2.2-rc-1

Type: Improvement
Reporter: Peter Niederwieser Assignee: Luke Daley
Resolution: Fixed Votes: 47

Attachments: Zip Archive buildSrc.zip     File sonar.gradle    


I got contacted by Julien Henry from SonarSource, saying that:

"[...] we are planning to stop supporting SQ Runner < 2.3 in one of the upcoming SQ releases (sooner or later).
I saw that you are still embedding SQ Runner API 2.0 in the Gradle plugin.
Could you please add in your backlog to update to SQ Runner API 2.3?"

Since relying on a particular Sonar runner version has caused some problems in the past, it would be even better to make the version and/or dependency configurable (cf. code quality plugins). The recent pull request for executing Sonar Runner in a separate process should make this even easier to implement.

Comment by Andrew Kowal [ 10/Jul/14 ]

Any plans for fixing this issue? A few days ago SQ 4.4-RC2 has been released and sonar-runner plugin doesn't work with that version.

Comment by Paul Macdona [ 31/Jul/14 ]

SQ 4.4 has now been released and I can confirm the sonar-runner plugin does not work.

Comment by Stéphane Nicoll [ 04/Aug/14 ]

Hey Peter, thanks for reporting this. We were also trying to use SQ 4.4 and are affected by this now as well. Thanks!

Comment by Holger Stolzenberg [ 05/Aug/14 ]

Our company just upgraded to SQ 4.4. All Gradle builds on the CI env now fail, because the Gradle "sonar-runner" plugin is not compatible with the SQ-4.4 API. As everything maven related is still working, we will not rollback. This effectively means that we have to disable Sonar analysis of all Gradle driven builds, which is definitely a bad thing for us. The builds are run using gradle-2.0.

The update of the sonar-runner and the sonar-runner-plugin are very much appreciated.

Should I file a separate issue for the sonar-runner plugin?

Comment by Timothy M. Rodriguez [ 05/Aug/14 ]

I've also hit this issue with Gradle 1.12 and Sonar 4.4. The error is an IllegalStateException because it can't download the libraries from the server.

Comment by Baptiste Chatrain [ 06/Aug/14 ]

Also hit the issue with Gradle 2.0 and Sonar 4.4. Same error : can't download the libraries from server

Comment by Chris Mousset [ 12/Aug/14 ]

We are also having this problem.

Comment by clt [ 12/Aug/14 ]

Upgrading Sonar to 4.4 caused all builds to fail:

[12:43:57]12:43:57.444 [ERROR] [org.gradle.BuildExceptionReporter] Caused by: java.io.IOException: Server returned HTTP response code: 400 for URL: http://<servername:port>/batch/
[12:43:57]12:43:57.444 [ERROR] [org.gradle.BuildExceptionReporter] 	at org.sonar.runner.Bootstrapper.remoteContent(Bootstrapper.java:125)
[12:43:57]12:43:57.444 [ERROR] [org.gradle.BuildExceptionReporter] 	at org.sonar.runner.Bootstrapper.downloadBatchFiles(Bootstrapper.java:158)
[12:43:57]12:43:57.444 [ERROR] [org.gradle.BuildExceptionReporter] 	... 59 more
Comment by Richard Bolkey [ 12/Aug/14 ]

Have now encountered this too.

Comment by Vikram Gadang [ 13/Aug/14 ]

Any work around for this?

Comment by Tomáš Kotula [ 14/Aug/14 ]

Caused by: java.io.IOException: Server returned HTTP response code: 400 for URL: http://<servername:port>/batch/

Here is what the url above returns in my case:

{"errors":[{"msg":"Bad filename: "}]}
Comment by Peter Niederwieser [ 14/Aug/14 ]

There isn't currently a workaround other than downgrading your Sonar installation. A pull request is underway that should fix this problem.

Comment by Richard Bolkey [ 14/Aug/14 ]

The workaround that I used was to generate the sonar-project.properties file (as expected by the sonar runner) using the sonarProperties property on the sonarRunner task (I added the action to do so onto the check task). Then I ran the sonar-runner cmd line tool where I generated the properties file. It works out acceptably since you can still leverage Gradle for all the configuration.

Comment by Peter Niederwieser [ 14/Aug/14 ]

That's indeed an option.

Comment by Holger Stolzenberg [ 15/Aug/14 ]

@Richard Bolkey
Is it possible that you share the sonar-project.properties that you created?

@Peter Niederwieser
Is there any release schedule for the pull request that you mentioned?

Comment by Mike Gilbode [ 15/Aug/14 ]

Attached is my sonar configuration using the runner in case it's useful to anyone. Just do apply from: 'sonar.gradle' from the root project. I first run build / test / jacoco before executing the sonar task.

Comment by Richard Bolkey [ 15/Aug/14 ]

This is what I did:

tasks.check << {

{ out -> tasks.sonarRunner.sonarProperties.store(out, "sonar project properties for project $project.name".toString()) }


and then just run SonarQube's sonar-runner from the command line.

Comment by Andrew Kowal [ 15/Aug/14 ]

Here is my quick fix for running analysis with new sonarqube.

The only thing you need to change in the build script is to replace old sonar plugin with:

apply plugin: 'sonarqube-runner'
Comment by Holger Stolzenberg [ 18/Aug/14 ]

Any chance the 'sonarqube-runner' plugin will make it into the next official gradle release?

Comment by Martin Flower [ 19/Aug/14 ]

We also have this problem.
Correct me if I'm wrong, but the solution is

  • upgrade the Gradle Sonar plugin (new version of gradle-sonar.jar)
  • replace the sonar runner in the Gradle distribution (new version sonar-runner-2.4.jar)
  • release a new version of Gradle (2.x.y)
  • and that these steps are in the hands of Gradleware?
  • not sure what the benefit of additional plugin sonarqube-runner would be in the distribution?
Comment by Holger Stolzenberg [ 19/Aug/14 ]

Just a quick thought. Of course it is better to only have one 'sonar-runner' plugin.

Comment by Serge SIMON [ 27/Aug/14 ]

Any news about this ?
I haven't been able to use the Andrew's quick fix (sorry, i'm new about gradle) - can't compile the provided .zip alone (sounds quite normal), but once reinjected in a full gradle 2.0 source package, it doesn't compile neither.
Could anyone provide somewhere the precompiled / patched needed jar(s) ?

Comment by Andrew Kowal [ 27/Aug/14 ]

Serge, you just need to place buildSrc directory to your project root. It will be automatically detected by gradle on the next build.

Comment by Nathan Redding [ 09/Sep/14 ]

Any rough idea when this will make it to release? We have a new instance of Sonar and would like to be able to publish to it from our gradle build. Also - seems weird that the plugin is released as part of gradle itself and not on an independent schedule.

Comment by Tad Reeves [ 09/Sep/14 ]

I see this was marked as fixed. Does this mean that it's going into the 2.2 release? If so, when will that make GA? I've been running Sonar on the 3.7.4 LTS version as a workaround for this, but owing to features in the pipeline, I'll soon need to update to v4+, which will break our gradle builds.

Comment by Oliver Trosien [ 11/Sep/14 ]

@Tad : you can test it by running a nightly version of gradle 2.2. That's what we are doing now.

@Peter: Was there a reason for not going straight to 2.4? Or is there a way to set the sonar-runner version in the build myself?

UPDATE: Found the flag myself. On the root project, you just need to do this:


{ toolVersion = '2.4' }
Comment by Tim Pizey [ 24/Sep/14 ]

With the current nightly and the above configuration

{ toolVersion = '2.4' }

on ubuntu with java
java version "1.6.0_45"
Java(TM) SE Runtime Environment (build 1.6.0_45-b06)
Java HotSpot(TM) 64-Bit Server VM (build 20.45-b01, mixed mode)

I fail with:

SonarQube Runner 2.4
Java 1.6.0_45 Sun Microsystems Inc. (64-bit)
Linux 3.13.0-32-generic amd64
INFO: Runner configuration file: NONE
INFO: Project configuration file: /ssd/home/timp/bbm/api/build/tmp/sonarRunner/sonar-project.properties
INFO: ------------------------------------------------------------------------
INFO: ------------------------------------------------------------------------
Total time: 0.003s
Final Memory: 2M/480M
ERROR: Error during Sonar runner executionINFO: ------------------------------------------------------------------------

ERROR: null
ERROR: To see the full stack trace of the errors, re-run SonarQube Runner with the -e switch.
ERROR: Re-run SonarQube Runner using the -X switch to enable full debug logging.
:sonarRunner FAILED

FAILURE: Build failed with an exception.

  • What went wrong:
    Execution failed for task ':sonarRunner'.
    > Process 'command '/usr/lib/jvm/j2sdk1.6-oracle/bin/java'' finished with non-zero exit value 1
  • Try:
    Run with --info or --debug option to get more log output.
  • Exception is:
    org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':sonarRunner'.
    at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:69)
    at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:46)


Caused by: org.gradle.process.internal.ExecException: Process 'command '/usr/lib/jvm/j2sdk1.6-oracle/bin/java'' finished with non-zero exit value 1
at org.gradle.process.internal.DefaultExecHandle$ExecResultImpl.assertNormalExitValue(DefaultExecHandle.java:365)
at org.gradle.sonar.runner.tasks.SonarRunner.run(SonarRunner.java:62)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:63)
at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.doExecute(AnnotationProcessingTaskFactory.java:218)
at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.execute(AnnotationProcessingTaskFactory.java:211)
at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.execute(AnnotationProcessingTaskFactory.java:200)
at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:579)
at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:562)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:80)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:61)
... 72 more


Comment by David Moshal [ 28/Sep/14 ]

So, as a relatively new user of Gradle, I'm really disappointed.

This sort of lock-in and inflexibility is exactly the same as that of Maven - no difference at all.

The Gradle plugin supports sonar-runner version 2.0, which is incompatible with the current sonarqube server (4.4), and additionally is no longer actively supported by sonarqube.

Yet, despite being reported by an actual founder of Gradle, presumably with far more knowledge of plugin internals than your average user, a month later it appears that no-one has been able to get the plugin to support the new version (2.3) of sonar-runner.

This for a plugin decribed in the Core Gradle documentation!

Someone should tell Hans Dockter to stop quoting Moshe Feldenkrais' phrase about "making the impossible possible", because, from what I can see, at least in this case, Gradle === Maven.

I guess Ant is the only way to go (again, for a core Gradle plugin) - such a joke.


Comment by Luke Daley [ 28/Sep/14 ]

David Moshal Gradle 2.2 allows you to choose your own Sonar Runner version. If you need this now you can use the nightly builds.

Comment by Tim Pizey [ 29/Sep/14 ]

@Luke but as noted above the current nightly is failing with error message 'null'

Comment by Luke Daley [ 29/Sep/14 ]

Tim Pizey this should be fixed as of a few days ago. Please try again.

Comment by Tim Pizey [ 05/Jan/15 ]

I have revisited this and, after deleting my cached gradle files, this worked.

Generated at Wed Jun 30 12:38:53 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.