SonarQube Gradle Plugin is not found by Artifactory - gradle

Question

(This question elaborates on a a question I asked earlier, but with enough differences that I think it warrants a separate question)
This post on the Gradle forums describes similar symptoms, but not quite the same as my problem.
Like the poster there, I get the error:
Plugin with id 'org.sonarqube' not found.
when trying to use the SonarQube Gradle plugin with the following in my build.gradle file:
buildscript {
repositories {
mavenLocal()
maven { url 'http://[artifactory-url]:8081/artifactory/plugins-release/' }
}
dependencies {
classpath("org.sonarsource.scanner.gradle:sonarqube-gradle-plugin:1.2")
}
}
apply plugin: 'org.sonarqube'
He says that his instance of Artifactory has cached the plugin, whereas mine hasn't. Similar to him, I'm behind a corporate firewall, and have no admin rights on Artifactory, but I can see that the plugins-release virtual repo does include both https://plugins.gradle.org/m2 and http://jcenter.bintray.com. Ordinarily, simply requesting a library from our Artifactory server makes it find and cache that library immediately, but in this case it is clearly failing.
When I remove the apply plugin... line, I see the following error:
> Could not find org.sonarsource.scanner.gradle:sonarqube-gradle-plugin:1.2.
Searched in the following locations:
file:/C:/Users/[username]/.m2/repository/org/sonarsource/scanner/gradle/sonarqube-gradle-plugin/1.2/sonarqube-gradle-plugin-1.2.pom
file:/C:/Users/[username]/.m2/repository/org/sonarsource/scanner/gradle/sonarqube-gradle-plugin/1.2/sonarqube-gradle-plugin-1.2.jar
http://[artifactory-url]/artifactory/plugins-release/org/sonarsource/scanner/gradle/sonarqube-gradle-plugin/1.2/sonarqube-gradle-plugin-1.2.pom
http://[artifactory-url]/artifactory/plugins-release/org/sonarsource/scanner/gradle/sonarqube-gradle-plugin/1.2/sonarqube-gradle-plugin-1.2.jar
So, I'm fairly sure that Artifactory is failing to find and cache the plugin. If I browse to https://plugins.gradle.org/m2/org/sonarsource/scanner/gradle/sonarqube-gradle-plugin/1.2/sonarqube-gradle-plugin-1.2.pom, I can get to the POM file, and the same for the JAR file, but I notice that if I browse to https://plugins.gradle.org/m2/org/sonarsource/scanner, it doesn't include 'gradle' as a subdirectory. I don't know if that's relevant, but perhaps that's the cause of the problem I'm seeing with Artifactory?
I'm not sure whether to raise this as a bug against the plugin, or if it's an Artifactory issue, or simply some kind of misconfiguration on our side. Any thoughts much appreciated!
Update with trace
Thanks to #drorb I got a trace from Artifactory, and found:
2016-04-12T10:28:40.918+01:00 Executing HEAD request to https://plugins.gradle.org/m2/org/sonarsource/scanner/gradle/sonarqube-gradle-plugin/1.2/sonarqube-gradle-plugin-1.2.pom
2016-04-12T10:28:40.924+01:00 Received status {} (message: 501) on remote info request - returning unfound resource
501 is 'not implemented', so I assume this is telling me that the plugins.gradle.org repo doesn't support HEAD requests, which seems to mean Artifactory can't query it properly. I'm surprised that it works for others though - perhaps there's some Artifactory config I can get changed to not do the HEAD request?
Further update with cause, but not really an answer
Further digging made me realise that the HEAD request does in fact give me a proper response (303 which leads to a 200), so I think the issue is connectivity from our Artifactory server. This doesn't seem worth adding as an answer, but I'll leave it here in case it helps someone else experiencing similar issues.

Answer 1

Here is a snippet of our Gradle conf, which works:
buildscript {
repositories {
maven {
url "http://[artifactory-url]:7980/artifactory/libs-release"
}
}
dependencies {
classpath "org.sonarsource.scanner.gradle:sonarqube-gradle-plugin:1.2"
}
}
apply plugin: 'org.sonarqube'
The only difference I can see is that we put /artifactory/libs-release in the maven url, while you have /artifactory/plugins-release. Perhaps you should try pointing to libs-release, and see if that works?