This message was deleted.

it happens for many other plugins as well .. strange that it was wokring and now suddenly out of blue everything is broken without doing any changes in our code

Sure it is still running. It will not be switched off. Just another of is outages. I thought Grape or up an own mirror though, but I might misremember.

but why can't gradle plugin repo redirect / proxy to mavenCentral instead since it is now the recommanded default repo?

It always was the canonical and more stable repo. I'm not aware of anyone recommending JCenter as default repo and if, then it was imho a bad recommendation. But you probably cannot simply change that, as it would change behavior and break builds because dependencies suddenly resolve differently.

I m not sure what should we do know.. we are using quite few plugins which have transitive dependencies and they are trying to be downloaded from jcenter .. is it possible to override it somehow? we are basically stuck because of that and we cannot build anything

if change your plugin repositories to add mavenCentral() first, and your plugins/dependencies are available there, then it shouldn't hit gpp/jcenter

That doesn't seem to be working for me. I wasn't declaring any extra plugin repositories, but my builds started failing. And adding that didn't help.

same here, my builds also fails.

not helping for me either

They are aware and also put some work-around in place minutes before your message: https://status.gradle.com/ If the dependencies you need are available on Maven Central or Plugin Portal a client-side work-around was already mentioned above. If the needed dependencies are only available on JCenter, there is no client-side work-around, besides using a caching proxy like Nexus Repository Manager to be independent of such outages.

thanks, the work-around they introduced worked.. The work-around mentioned above didn't work (as @thadhouse mentioned as well), it was still trying to download the transitive dependencies of a plugin via the plugin repo which was keeping redirecting to jcenter. yeh, using a nexus proxy repo is definitely a good idea, we are using it for mavenCentral, but so far we haven't use it for gradle plugins repo

Hi! I'm still getting the error:

What went wrong:
A problem occurred configuring root project 'backend'.
> Could not resolve all files for configuration ':classpath'.
   > Could not find com.sonatype.nexus:nexus-platform-api:4.0.0-01.
     Searched in the following locations:
       - <https://plugins.gradle.org/m2/com/sonatype/nexus/nexus-platform-api/4.0.0-01/nexus-platform-api-4.0.0-01.pom>
     If the artifact you are trying to retrieve can be found in the repository but without metadata in 'Maven POM' format, you need to adjust the 'metadataSources { ... }' of the repository declaration.
     Required by:
         project : > org.sonatype.gradle.plugins.scan:org.sonatype.gradle.plugins.scan.gradle.plugin:2.5.1 > org.sonatype.gradle.plugins:scan-gradle-plugin:2.5.1
   > Could not find com.pinterest.ktlint:ktlint-core:0.47.1.

The workaround mentioned didn't work as well. I'm not sure what to try now. Any recommendations?

Maven Central work-around should work as it is present there. Try with

--refresh-dependencies

in case the resolution cache just has stale information.

No, still getting it. I'm running locally:

$> ./gradlew assemble --refresh-dependencies                                                                                                  

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring root project 'rillet-backend'.
> Could not resolve all files for configuration ':classpath'.
   > Could not find com.sonatype.nexus:nexus-platform-api:4.0.0-01.
     Searched in the following locations:
       - <https://plugins.gradle.org/m2/com/sonatype/nexus/nexus-platform-api/4.0.0-01/nexus-platform-api-4.0.0-01.pom>
     If the artifact you are trying to retrieve can be found in the repository but without metadata in 'Maven POM' format, you need to adjust the 'metadataSources { ... }' of the repository declaration.

Also with the explicit "Maven Central"? Without it, I think it will not work as they only mirror libs found directly in JCenter, not the ones JCenter forwarded to Maven Central.

yes, in the build.gradle.kts I have:

repositories {
    mavenCentral()
}

nexus-platform-api:4.0.0-01 is not in the plugin repo while ago there was just some older version 3.* and now there isn't any

yes, in the build.gradle.kts I have:

That is not the mentioned work-around. You need to define it as plugin repository in your settings script, not as repository for your production code.

nexus-platform-api:4.0.0-01 is not in the plugin repo while ago there was just some older version 3.* and now there isn't any

There never was any. The plugin portal redirects to JCenter for libs it does not have itself and JCenter forwards to Maven Central for libs it does not have. But the server-side work-around put in place by the Gradle guys is just a JCenter mirror without the forwarding to Maven Central, thus it is currently not resolvable if you only have the plugin portal as plugin repository.

I thought they were equivalent. With that (and swapping some dependencies around) I have the build working again. Thanks for the help!

I think the gradle team needs to take issues like this more seriously. Every time this happens (and it happens a lot) they just throw their hands up, and throw the blame elsewhere, without ever realizing that builds being down is a major issue, and a build system that can’t build is useless. I’d like to see actual failure analysis done, and steps gradle can take to avoid these problems in the future. As much as they want to think it’s not their problem when this happens, everyone is going to blame gradle, as it’s gradle builds that break when this happens.

What makes you think they just blame someone else and don't do anything? That's not the case. They majorly improved the situation the last time there was a longer JCenter outage and also in the meantime put up a stand-by mirror of JCenter to which they switched as a work-around currently. They are very well aware this is a problem and are improving on it.

It always just seems like the first response is to say it’s just another outage, rather then we’ll look into it. That was definitely the case with past outages. And I’d like to see blog posts happen after the fact explaining what happened, and how gradle is working to mitigate the issues in the future. Like I had no clue that they started adding a mirror after last time, because they never did a post mortem for the last failure (at least a public one). It’s good that they are, but it seems like the stand by mirror maybe should be the default, rather then waiting for jcenter to break. Especially if it happens in the middle of the night, like normally seems to be the case, and it takes hours for someone to flip the switch to the mirror. With jcenter being read only, it seems like it’d be really easy to make sure the mirror always works, since there would never be any package update to it.

I actually agree with @thadhouse. I just didn't want to be the one to complain, but I was about to say basically the same. I've convinced our company to migrate from maven to gradle based on the recent hype (and yes, I m still convinced it has certain advantages, especially when using Kotlin DSL), even our legacy monolith enterprise apps with 40+ subprojects and many dfiirent customer dist builds are now converted, I spent months on it. And now, when it gets down I get it back in my face from my colleagues. I know the product is free for use etc. And I really enjoy using it most of the time, but it is hard to have some critical system based on it, especially when using its plugins, when it might happen that its primary plugin repo might stop providing plugin dependencies. Maybe the dependencies of each published plugin should be just stored on plugins.gradle.org server and not delegate anywhere else? I don't know. It actually didn't took only hours, but almost 2 days, our build were failing already on saturday night and it only got fixed today. 😐

It always just seems like the first response is to say it’s just another outage

I'm not affiliated with Gradle, just sharing my experience.

That was definitely the case with past outages. And I’d like to see blog posts happen after the fact explaining what happened, and how gradle is working to mitigate the issues in the future.

https://blog.gradle.org/plugins-jcenter

Like I had no clue that they started adding a mirror after last time, because they never did a post mortem for the last failure (at least a public one).

Not true, see above

Hey folks, we have been working on reducing the impact of the JCenter outage. https://status.gradle.com/ contains updates. And yes, severing ties with JCenter fully is complicated and will take time. And will most likely break builds when it happens. We will communicate clearly whenever that is about to happen.

are there still issues with plugins/jcenter? We're just starting to see this in our CI

problem seems to be back

We are looking into it.