Plugin Portal Dependency Resolution Failing Due to JCenter Usage

Help/Discuss Plugin Portal
1

As of this AM dependency resolution is failing for my Gradle builds. I noticed this because Jitpack builds are failing, but I can reproduce the problem locally by adding the --refresh-dependencies flag.

The problem seems to be being caused by JCenter:

Could not resolve com.pinterest.ktlint:ktlint-core:0.47.1.
     Required by:
         project : > org.jmailen.kotlinter:org.jmailen.kotlinter.gradle.plugin:3.12.0 > org.jmailen.gradle:kotlinter-gradle:3.12.0
         project : > org.jmailen.kotlinter:org.jmailen.kotlinter.gradle.plugin:3.12.0 > org.jmailen.gradle:kotlinter-gradle:3.12.0 > com.pinterest.ktlint:ktlint-reporter-json:0.47.1
         project : > org.jmailen.kotlinter:org.jmailen.kotlinter.gradle.plugin:3.12.0 > org.jmailen.gradle:kotlinter-gradle:3.12.0 > com.pinterest.ktlint:ktlint-reporter-html:0.47.1
         project : > org.jmailen.kotlinter:org.jmailen.kotlinter.gradle.plugin:3.12.0 > org.jmailen.gradle:kotlinter-gradle:3.12.0 > com.pinterest.ktlint:ktlint-ruleset-experimental:0.47.1
      > Could not resolve com.pinterest.ktlint:ktlint-core:0.47.1.
         > Could not get resource 'https://plugins.gradle.org/m2/com/pinterest/ktlint/ktlint-core/0.47.1/ktlint-core-0.47.1.module'.
            > Could not GET 'https://jcenter.bintray.com/com/pinterest/ktlint/ktlint-core/0.47.1/ktlint-core-0.47.1.module'.
               > Read timed out

Note that my project has no explicit jcenter dependencies, nor does jmailen.kotlinter. However, it seems that the Gradle Plugin portal is still trying to resolve dependencies on jcenter. Which seems to be down or broken or misconfigured somehow, although it’s hard to tell how or why. Particularly given that half of the things you find when searching claim that it was sunset a long time ago.

My understanding is that JCenter is in read-only mode. But it also seems like something changed recently, since these dependencies were resolving not too long ago. Or perhaps attempts to resolve them using JCenter were failing correctly and causing the plugin portal to move on to other options.

Does anyone know what is going on, or have a link for a page with status updates? http://status.bintray.com/ it itself, down, which is fairly unhelpful, since it’s unclear whether it’s down due to the sunsetting or down because something else is badly broken.

2

Can confirm I’m also having this same issue, but for log4j-core, even though I have no explicit jcenter dependencies

2022-10-30T13:28:30.769-0500 [DEBUG] [org.apache.http.impl.execchain.RedirectExec] Redirecting to 'https://jcenter.bintray.com/org/apache/logging/log4j/log4j-core/maven-metadata.xml' via {s}->https://jcenter.bintray.com:443
1 Like
3

FWIW, this problem seems confined to the Gradle plugin portal, which I believe is still trying to resolve dependencies on JCenter. (Strong belief, given the error output.)

I suspect this because I have two projects both using the same “org.jmailen.kotlinter” dependency. One builds fine on Jitpack, but it’s a project with submodules and the plugin is marked apply false in the root build.gradle.kts. (Either that or I snuck the build in right before this outage started.) The other has no submodules and fails trying to resolve dependencies for this plugin.

With only scant understanding of that system, my suspicion is that it is expecting JCenter to return 404s for packages not hosted there so that it can try other repositories, but currently HEAD and GET requests to JCenter are timing out and not returning a 4xx.

Given that JCenter is sunset and in read-only mode, I can’t imagine that there are many resources being devoted to maintaining it or ensuring high availability. So it’s probably time for for the Gradle plugin portal to continue working or at least retry properly across any and all JCenter failures, regardless of how they manifest. Particularly in cases like this, where I suspect the failed resource isn’t even hosted on JCenter in the first place.

4

This change to settings.gradle is working for me:

// settings.gradle
pluginManagement {
    repositories {
        mavenCentral()
        gradlePluginPortal()
    }
}

HT to Received status code 524 from server: Origin Time-out - #6 by SteinGaming. Essentially forces Gradle to try Maven Central first and avoid the JCenter outage.

5

This sadly did not fix it for me, still redirected to bintray in logs.

6

I had to also disable Gradle metadata as well as some old plugins were declaring they had this information (*.module) but its missing from the plugins repo (must be fetched from jcenter):

// settings.gradle
pluginManagement {
  repositories {
    mavenCentral()
    // Ref: https://github.com/gradle/gradle/issues/15406#issuecomment-1020352934
    gradlePluginPortal {
      this as MavenArtifactRepository
      metadataSources {
        mavenPom()
        ignoreGradleMetadataRedirection()
      }
    }
  }
}
1 Like
7

I have noticed the same problem, and a simple check with HTTPie confirms that it’s a redirection problem:

 ~ î‚° http https://plugins.gradle.org/m2/org/jreleaser/jreleaser-model/1.0.0/jreleaser-model-1.0.0.pom                                                                                                                                                                                                                                                                                                                                           3080ms î‚ł Mon Oct 31 12:09:03 2022
HTTP/1.1 303 See Other
...
Location: https://jcenter.bintray.com/org/jreleaser/jreleaser-model/1.0.0/jreleaser-model-1.0.0.pom
1 Like
8

Right. But JCenter is supposed to continue on in read-only mode indefinitely, right? So it’s not clear what changed recently, or why this would suddenly start causing a problem. (I’d assume if something changed on the Gradle end recently they’d have an eye out for the problem and have reverted the change.)

9

Just the usual regular JCenter outage which caused me to never like JCenter. :slight_smile:

1 Like
10

Has been restored.
JCenter works now.

11

maybe the question is why does Gradle still use JCenter instead of MavenCentral?

1 Like
12

Because it would be a breaking change breaking many builds out there in the wild that still use plugins that need dependencies only available on JCenter. This switch needs to be done carefully, is complicated and needs much communication whenever it happens.

13

I understand the need to continue to pull dependencies from JCenter for builds that need them. But JCenter being down should not fail builds that do not use dependencies hosted on JCenter. Which is what was happening recently.

Given that JCenter is in read-only mode, it should also be possible to mirror all of its content on a separate server and then do a simple DNS switch—or at least have the mirror as a failover option.

14

They do have a failover mirror

15

Which clearly wasn’t working recently. I suspect that the dependency resolution process is expecting missing dependencies to fail in a certain way (e.g., 404), and recently JCenter was FUBAR’d to the point that it was timing out reads instead of failing “properly”.

Anyway, as I suggested above, it would be more stable of the plugin repository didn’t assume any particular behavior from JCenter whatsoever.

16

Don’t get me wrong, I fully agree that they should break the tight ties with JCenter and they also agree and working on it, it just needs time and care as it seems to be a more complex task than it might seem from an external point of view.
And regarding the fail-over mirror, it worked once they activated it, they just needed to switch manually I think, probably because JCenter did just not fail completely or just hang or something like that as far as I have observed, but that’s just a wild guess.