This message was deleted.

Like I've heard MULTIPLE times they've made a mirror of jcenter. Why is that mirror not unconditionally being used. I can tell by the logs that jcenter is still being accessed transitively.

Any reason you (still) haven't configured your build to look into

mavenCentral()

before the

gradlePluginPortal()

? and/or configure those repositories with content filtering to only pick from the Plugin Portal what it's actually capable of serving?

Because we have a lot of builds, and where is that documented? Why have the plug-in portal block then?

If it's been specifically uploaded to the plugin portal, then it has nothing to do with jcenter.

I just assumed it was jcenter interference, because when I’d go to the url my build would print out, it’d redirect to jcenter. If it was jcenter that’s fine, but there’s still the case of it not serving an artifact that was definitely there. About half my CI runs would work, the other half wouldn’t.

I'm not aware of any new outage. There would be more people complaining here and on the forums than just you, so I'd assume you have a problem that you just think is related to JCenter. The mirror of JCenter cannot be unconditionally used, because the mirror only mirrors the things present on JCenter directly. But the real JCenter forwards to Maven Central every request it cannot serve itself. So just always using the mirror instead of JCenter would break builds out there that use transitive dependencies only available on Maven Central that did not configure Maven Central explicitly. If it were that easy to replace JCenter on the plugin portal side, they would already have done it. Also blaming the build tool that it does not work properly is absolutely unfair. The build tool is doing exactly its job. It is your build that is using an unreliable service that is provided for free. Yes, it is a service provided by Gradle Inc. and it relies on the unreliable JCenter which will be fixed in the future. But still, it is a free service you rely on and you have no contract that guarantees any uptime. If you want a more reliable service, use a caching proxy like Nexus repository manager that can cache the dependencies your builds need, is fully under your control and has any uptime guarantees you want. Again, the build tool itself is working perfectly fine, it is your build that is using an unreliable service if it is the service actually, which I doubt in this case.. 😉

If the real jcenter can forward to mavencentral, why can’t the mirror? That argument makes no sense. Also, yes the actual Java code works fine, but gradle is the whole ecosystem imo. Using an unreliable service that is built in, and is the default unless you explicitly go out of your way to do other things, should directly be considered part of the build tool. And as I said later, I didn’t think it was a jcenter issue. That was kind of just a side thing. It was a dependency directly uploaded to the plug-in portal that was failing to download. It was uploaded about 5 minutes before the failure started occurring, so my guess is something was going weird with distributing the new binaries across all the servers. I’d just never seen that happen before, so assumed something was starting to fail in the portal itself.

If the real jcenter can forward to mavencentral, why can’t the mirror? That argument makes no sense.

I didn't say it cannot, I said it does not. Probably because it was brought up as a quick counter-measure during one of the outages and not properly designed as a permant replacement. I didn't make any argument, just answering your question.

Also, yes the actual Java code works fine, but gradle is the whole ecosystem imo.

Using an unreliable service that is built in, and is the default unless you explicitly go out of your way to do other things, should directly be considered part of the build tool.

Well, opinions differ. You are surely right to some extent. And to the extent you are right, the service they provide is also good and stable and if something is failing is usually rapidly fixed or worked-around, and they are working on a proper solution to get rid of JCenter completely, it is just not as easy as you might think. But still, depending on a free service someone else provides and for which you neither pay, nor have any SLA, is always risky and can go havoc. It works fine for the most of the time and has a great uptime and if it actually is down and you loose money or whatever because you relied on the free service provided to you, then sorry, imo it is your fault for not having some backup plan like having a caching proxy for the things you need to work. :-)

And as I said later, I didn’t think it was a jcenter issue. That was kind of just a side thing. It was a dependency directly uploaded to the plug-in portal that was failing to download. It was uploaded about 5 minutes before the failure started occurring, so my guess is something was going weird with distributing the new binaries across all the servers. I’d just never seen that happen before, so assumed something was starting to fail in the portal itself.

If you think there is something bogus in the portal, you should open an issue at https://github.com/gradle/plugin-portal-requests/issues, this is a community server, so just complaining here might not reach the appropriate ears. ;-)