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.

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

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

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?

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.

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

We are also having this problem.

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

Have now encountered this too.

Any work around for this?

Here is what the url above returns in my case:

{"errors":[{"msg":"Bad filename: "}]}

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

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.

That's indeed an option.

@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?

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.

This is what I did:

tasks.check << {
file("$buildDir/sonar-project.properties").withWriter

}

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

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'

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

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?

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

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) ?

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

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.

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.

@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:

sonarRunner

With the current nightly and the above configuration

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: EXECUTION FAILURE
INFO: ------------------------------------------------------------------------
Total time: 0.003s
Final Memory: 2M/480M
ERROR: Error during Sonar runner executionINFO: ------------------------------------------------------------------------

ERROR: null
ERROR:
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)

[snip]

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

BUILD FAILED

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.

David

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.

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

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

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