Thanks for mentioning this. We should definitely do this before it's too late! But to clarify the timeline:

That means it's still serving binaries until February 1st, 2022. I'll also mark it as bug, so we won't forget to fix this!

Thanks for the additional info. Good to know we aren't on such a tight deadline.

I'm seeing a large number of CI build failure for expo-av with connections to bintray/jcenter being closed trying to download OKio OKhttp (on app center). I hope this can get prioritized on the sooner end.

Any progress on this one?

#14409 Addressed most of this. jcenter is still present in the bare minimum template, but mavencentral is there now too.

https://status.bintray.com/ is down for 3 days

@n0mer - the status page is down but the service is up. jcenter is going to remain up as a read-only service indefinitely. you may be able to get some information about the status page from bintray, but they have not discussed anything publicly as far as i know.

i've been in touch with react-native folks at meta like @cortinico to see if they can coordinate getting older artifacts required for react-native 64 and 63 published to maven central, so we can remove jcenter entirely. that said, in the next sdk release we will update react-native to 66 or 67, and there are no longer any dependencies from react-native itself on jcenter in react-native 65+.

Thanks, @brentvatne

A build of mine just failed with the following error:

Could not GET 'https://jcenter.bintray.com/com/facebook/react/react-native/maven-metadata.xml'. Received status code 502 from server: Bad Gateway

[stderr] FAILURE: Build failed with an exception.
[stderr] * What went wrong:
[stderr] Could not determine the dependencies of task ':app:lintVitalRelease'.
[stderr] > Could not resolve all artifacts for configuration ':app:debugRuntimeClasspath'.
[stderr]    > Could not resolve com.facebook.react:react-native:+.
[stderr]      Required by:
[stderr]          project :app
[stderr]          project :app > project :expo
[stderr]          project :app > project :react-native-svg
[stderr]          project :app > project :react-native-tesseract-ocr
[stderr]          project :app > project :expo > project :expo-modules-core
[stderr]          project :app > project :expo > project :expo-dev-launcher
[stderr]          project :app > project :expo > project :expo-dev-menu
[stderr]          project :app > project :expo > project :expo-dev-menu-interface
[stderr]          project :app > project :expo > project :expo-splash-screen
[stderr]       > Failed to list versions for com.facebook.react:react-native.
[stderr]          > Unable to load Maven meta-data from https://jcenter.bintray.com/com/facebook/react/react-native/maven-metadata.xml.
[stderr]             > Could not get resource 'https://jcenter.bintray.com/com/facebook/react/react-native/maven-metadata.xml'.
[stderr]                > Could not GET 'https://jcenter.bintray.com/com/facebook/react/react-native/maven-metadata.xml'. Received status code 502 from server: Bad Gateway

If I try loading that URL in a browser I get the following:

Error: Server Error
The server encountered a temporary error and could not complete your request.

Please try again in 30 seconds.

Fortunately I was able to workaround it by removing all references to jcenter() in all of the build.gradle files using a Config Plugin and patch-package:

wodin/expo-ocr-example@f896757

JCenter down again, unable to develop on Android for the second time in the past week. Part of me has to think that this is JFrog's way of forcing everyone to switch without fully shutting down their archive.

"Hey, we're going to leave the archive up indefinitely....... buuuuuuut our reliability is now questionable. Might wanna just switch right? (btw this totally has nothing to do with reducing our server costs)"

Does anyone know if there's any way to configure build.gradle to override allprojects.repositories for the project + any subdependencies so we can blacklist jcenter for all deps or replace it with a mirror?

From yesterday I am receiving constant error on 'Could not get resource 'https://jcenter.bintray.com/org/webkit/android-jsc/maven-metadata.xml'.' when using EAS build on Android. I am on SDK 42, can this issue be resolved by updating the SDK or any other way?

@edit

It is working now, can anyone say what was the issue? Hard to tell why build fails and works again in the matter of hours without any code modification on EAS build service.

Removing seems is not solving problem because expo's some dependencies are not published there such as flipper-fresco-plugin (0.54.0). Central has 0.75.0 and above.

it looks like jcenter is down again. we're in talks with the react-native folks at meta about getting older artifacts that currently only exist on jcenter mirrored on maven central, hopefully we can get that done and then move off of depending on jcenter in sdk 44 projects.

@brentvatne thanks for looking into this.

As far as I can tell because expo-av depends on a dependency that's on jcenter, if jcenter goes down people are unable to build/CI/release. #14185

https://github.com/expo/expo/blob/master/packages/expo-av/android/build.gradle#L79

https://mvnrepository.com/artifact/com.google.android.exoplayer/exoplayer/2.9.2

Have I got this right? If so, best of luck getting them mirrored :)

@henrymoulton - that looks correct. we may need to bump the exoplayer version: google/ExoPlayer#5246 (comment)

yup I thought about trying to patch-package my way out but the comments

  // Newer version introduces dependency versions conflict
  // on 'com.android.support:support-annotations'
  api 'com.google.android.exoplayer:exoplayer:2.9.2'

are scaring me off for now, will tune in tomorrow to see if jcenter is back.

Have I got this right? If so, best of luck getting them mirrored :)

That's correct. The specific package, exoplayer, is hosted on Google Maven repo and available there since version 2.13.3: https://maven.google.com/web/index.html?q=exoplay#com.google.android.exoplayer:exoplayer

Yes, it's feasible to ask companies to re-upload older version of artifacts to other repos (being them MavenCentral or Google Maven repo), but that takes time and effort and should not be the preferred solution IMHO.

Updating versions (i.e. the Expo SDK version) is way faster than trying to convince library authors to re-upload older artifacts to other repos.

https://testfairy.com/blog/jcenter-and-bintray-is-shutting-down-what-to-do/

March 31st, 2021	No more submissions will be accepted to JCenter.
April 12th, 26th, 2021	The service will brown-outs to remind users about the services that are going away on May 1st. (Specific hours will be advertised in the Bintray status page.)
May 1st, 2021	Bintray services will no longer be available.
**February 1st, 2022	JCenter will no longer be available for non-Artifactory clients.**

Is this the EXPO apocalypse?

My comprehension of all that is if I need to build my app after the February 1st, I need to remove everything related to expo..

Tell me that I misunderstood something.

@t1gu1 my understanding from @brentvatne's comment is that Expo is planning on making sure that this doesn't happen by before the 1st of February

They say they will keep their repo as a read only mirror indefinitely, according to https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/

UPDATE 4/27/2021: We listened to the community and will keep JCenter as a read-only repository indefinitely. Our customers and the community can continue to rely on JCenter as a reliable mirror for Java packages.

although we have already seen that «reliable» it is not…

i'll repeat my above comment:

we're in talks with the react-native folks at meta about getting older artifacts that currently only exist on jcenter mirrored on maven central, hopefully we can get that done and then move off of depending on jcenter in sdk 44 projects.

in the worst case, we'll continue to depend on jcenter until sdk 45.
in best case, folks at meta are able to do us a favor and upload artifacts required for react-native 64 to mavencentral and jfrog has figured out the infra issues and will continue to keep jcenter running as read-only indefinitely so older versions are not impacted at all.

i'll lock this issue for now so that this remains the most recent comment, in order to ensure that everybody has the most relevant information