I think I found the culprit in my case:
This is part of our build.gradle file:
plugins {
id "nebula.ospackage" version "4.9.3"
}
When using the plugin this way (the new mechanism), the Gradle plugin system first tries to retrieve this file:
https://plugins.gradle.org/m2/nebula/ospackage/nebula.ospackage.gradle.plugin/4.9.3/nebula.ospackage.gradle.plugin-4.9.3.jar. The path is generated by the name and version of said plugin. For almost all plugins, this jar-file will not actually exist, but there is a pom-file there referencing the real artifact.
Anyway, said URL actually redirects (303) to https://jcenter.bintray.com/nebula/ospackage/nebula.ospackage.gradle.plugin/4.9.3/nebula.ospackage.gradle.plugin-4.9.3.jar, which then redirects (302) to https://repo.jfrog.org/artifactory/libs-release-bintray/nebula/ospackage/nebula.ospackage.gradle.plugin/4.9.3/nebula.ospackage.gradle.plugin-4.9.3.jar?referrer.
As you can see, there is some room for error here. I don’t know which of these three hosts actually timeouts so often, but it is most likely not plugins.gradle.org, because this would affect all other plugins, too.
How to workaround
In case there is no timeout on any of the mentioned hosts, Gradle finally finds out that the jar-file indeed does not exist (404). Damn, all this work for nothing! Gradle then tries to retrieve the corresponding pom-file instead, which is actually hosted directly at https://plugins.gradle.org/m2/nebula/ospackage/nebula.ospackage.gradle.plugin/4.9.3/nebula.ospackage.gradle.plugin-4.9.3.pom without all this redirect stuff.
The pom-file only exists to be found by the new mechanism to include Gradle plugins (the plugin-block shown above). The pom-file defines com.netflix.nebula:gradle-ospackage-plugin:4.9.3 as its sole dependency, which is the actual plugin that we actually want!
The obvious workaround is to skip all these redirects and reference the actual plugin-artifact (com.netflix.nebula:gradle-ospackage-plugin:4.9.3) directly. In case of the “nebula.os-package”-plugin, this can be done by using the old mechanism to use Gradle plugins:
buildscript {
repositories {
maven {
url "https://plugins.gradle.org/m2/"
}
}
dependencies {
classpath "com.netflix.nebula:gradle-ospackage-plugin:4.9.3
}
}
As you can see, the “classpath” directly references the correct artifact that can be retrieved without all these redirects caused by the new plugin mechanism.
Extra information for users of Sonatype Nexus
We use a Sonatype Nexus repository as a proxy to the Gradle Plugin Portal, so that we don’t hammer it with excessive plugin-downloads every few minutes. Unfortunately, Nexus doesn’t work well with the new plugin mechanism of Gradle.
I was curious why we are even affected by all these timeouts, as Nexus should cache all downloaded Gradle plugins. But as explained above, when using the new mechanism to retrieve gradle plugins, Gradle first tries to download a non-existent jar-file (which will be the case for almost all plugins when including them the new way). Unless you configured your Nexus-proxy to use a “Negative cache” (“Not found cache”), these requests will always hit the actual hosts.
The workaround stated above also applies in this case.
My two cents
I think it is wrong for Gradle to try to directly download the jar-file when using the new mechanism, as this request (as far as I can see) will always result in a 404. When using the new mechanism Gradle should download the pom-file first, which then references the actual artifact as a dependency. This would prevent a useless 404-request and skips a lot of redirecting through jfrog and bintray).
