[Deadline: Feb 1st, 2022] JCenter is being sunset -- What's the plan for react-native?

[fbartho]

Introduction

Disclaimer: I'm neither an Android expert nor do I know the right terminology here

JCenter / Bintray are going away, and this will have an impact on react-native Android (Core), and probably all react-native Android apps.

JCenter / Bintray is a service for build artifacts for Java projects, and jcenter() can be found in the build.gradle and other locations for the default react-native template.

Details

• Deadline: Feb 1st, 2022
• Announcement: https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/
• Search of react-native's codebase for JCenter

Discussion points

1. What's the impact of this change? -- my guess: mass disruption to all android react-native apps
2. Are there alternatives to JCenter for the react-native community?
3. What's the plan for migrating react-native repos? -- depends on what maintainers / facebook plan to do?
4. What's the plan for communication with the community?

[kelset]

I think that the quick answer is that:

• we'll have to do PRs against the main repo to remove all references to jcenter() from gradle configs (probably in favour of mavenCentral()...? ). And see what happens.
• existing React Native apps will have to do a similar process on their own.
• we'll have to update the template to not have jcenter() in the build.gradle too.

---

EDIT: me and my colleagues tried to dive a bit more into this problem and it sounds like either it's gonna an easy fix or a mess.

[fbartho]

Thanks for taking a look @kelset -- I'm expecting it to be a whole mess too!

As I'm not deep in the android ecosystem, I don't even know if the jcenter() call is actually reaching out to a "host" of the content, and if mavenCentral() is: A. a different host B. a superset of JCenter(), or C. something else.

I have some dozens of android/ folders in my node_modules libraries, so even if I update my app to use mavenCentral() I don't know what will happen to all the libraries. -- It's pretty much guaranteed that all the libraries won't ship an update in the next month or two, so… This is going to be fun.

Forgive my lack of name recognition, but are you "the powers that be" in the react-native community, or do you know how to escalate this?

[kelset]

yeah it's likely going to be a wild ride 🤠

Forgive my lack of name recognition, but are you "the powers that be" in the react-native community, or do you know how to escalate this?

Ahahah no worries at all - I think it's a fair question! I don't work for FB but I think that posting it here is a great start, I am in the "RN Contributors" discord so I'll try to put this in front of the team and see what they say (in all fairness, it has already been reported there by @empyrical ;) )

[Naturalclar]

Update about the deadline, it seems like JFrog has extended the jcenter sunset. They'll be serving packages until February 1st, 2022

https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/

[pke]

Except jcenter are down right now. This again proves the point that build pipelines should have zero external dependencies. Anyone knows how to setup a company wide maven-repo that it manually curated?

[mifi]

Yea, they say All systems operational at https://status.bintray.com/ but packages have been sporadically returning 502 bad gateway for over a day now. I think it's time to switch!

[Naturalclar]

I believe we're waiting for a new version of gradle which doesn't depend on jcenter, gradle 7.0.
https://blog.gradle.org/jcenter-shutdown

Can't do much on react-native's (or any other cross platform's) side until that is resolved

[kelset]

Small update on this, we have found a potential workaround on our side, you can see it in this PR: microsoft/react-native-test-app#278

Basically we point the old trove4j dependency to the new IntelliJ one with a local script.

[mikehardy]

@Naturalclar "I believe we're waiting for a new version of gradle..."

I do not understand ? The dependencies of react-native (direct or transitive) must be published in non-jcenter repositories, and you remove jcenter() from your build scripts, and you are "jcenter clean", how is a new version of gradle going to publish the artifacts to other repositories for you 🤔 ?

There's real work to be done, quite specifically re: yog'a proguard-annotations artifact. I don't think waiting on anything is a good plan.

That said, behold: gradle 7 is here! So I guess if that was some reason for waiting, there's no reason to wait.

Copy-splatted in here from react-native-community/releases#221 (comment)

This is just context but I did a deep dive on "jcenter/bintray is going away" to see if I could purge react-native-device-info module of jcenter uses - including the example app and it appears yoga's 'proguard-annotations' artifact is the key to it all. There are 3 items total

1- flipper itself (requested above)
2- flipper dependency on fbjni-android-only (fixed in flipper 0.79+, so we actually need a newer one than is even on main dev branch but wait...)
3- flipper dependency on yoga progaurd-annotations which is still published on jcenter only but tracked here and will require a still-newer flipper unless they publish old artifacts on jitpack or mavenCentral

[mikehardy]

(there's separate discussion here about whether modules will update - I can't see a way around it, if they don't people will have to fork and publish to jitpack until the repo is updated - and if it's not updated for such an important issue then repo should be forked, IMHO)

[mikehardy]

Had a brainstorm on a solution that could be made to work similar to jetifier - a small centralized solution that adds forward-compatibility to projects dependent on old versions and can't upgrade for whatever reason. Realized after posting it that it would be better here:

facebook/yoga#1065 (comment)

---

@d4vidi that's an interesting approach, you are on to something there. This is a potential start towards something automated for people that can't update.

Examine this if you have time: https://github.com/ankidroid/Anki-Android/blob/master/AnkiDroid/robolectricDownloader.gradle - the idea is to pre-download maven artifacts you'll need later

I wrote that in order to have external dependency download de-flaked in an E2E CI type pipeline where the downloads were failing builds and giving me a fail signal outside of my code changes. With that and an exponential-back-off-retry I have great signal to noise.

But - if the general idea of "you can have a gradle task that downloads dependencies before your real build" is combined with the idea of "react-native jcenter dependencies may be downloaded"...

1- store the problematic in-use artifacts on the official react-native github somewhere (or on their respective project pages) as downloadable things - have a known list of them, I think there are only a handful (yoga android-annotations, 2 flipper plugins, fbjni)

2- write a downloader script for them like the above

3- integrate that in to patch releases of RN CLI?

It could be just as terrible + functional as https://github.com/mikehardy/jetifier :-), which is and was kind of gross but also just glossed over the whole AndroidX migration for everyone at once and made it go away...

---

If done well it requires no external approval or waiting actually - a repo could simply get them now even if it wouldn't be officially blessed, write the task and throw them in the local ~/.m2 and integration of the package is to add an apply ... statement in your build script (something semi-normal for packages to ask) and make sure mavenLocal is in your repo list in build.gradle, so as a proof-of-concept it could be demonstrated prior to involving the official repos (so the artifacts are more official) or the RN CLI (so the task is included / default-on like jetifier for everyone)

Note that it may be useful to develop this capability regardless of the dependencies we know about being fixed, as there is always some other thing we did not know about. And if we have this capability then someone somewhere can get a copy of the artifact, post it in the downloadable spot, we can add it to the npm package for an update to the list and everyone is auto-fixed again until versions are actually updated (similar to jetifier which did have some missing edge cases at the start until adoption was 100% and is still a lifesaver for folks on RN59 etc)

[mikehardy]

I'm going to try it. Everything's more fun with more people, come collaborate if you want to try it with me: https://github.com/mikehardy/jcenterizer/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc

[d4vidi]

@mikehardy I might be able to help at some point on Thursday. 'Promise to approach you.

[d4vidi]

@mikehardy 'ended up having a hectic Thursday. Have you managed to make progress so far?

[mikehardy]

I totally understand @d4vidi my country just went back in to lockdown while we were on a business trip within the country and it scrambled my week completely. At any rate I don't have code to show yet - it's still at the research phase but

1. your idea for it to be a gradle plugin is perfect I think, the whole idea is a "shim" basically, and it means we would be isolating the shim right at the layer we are shimming using the same tools etc. Now that I've seen that idea I think any solution that is not a gradle plugin will need to have a strong reason why

2. having a "known-good download location" for orphaned artifacts is one way to handle things, but @kelset pointed me to another method also where you may force resolution of artifacts to ones that are generally available https://github.com/microsoft/react-native-test-app/pull/278/files#diff-ddc2bac746c108f9464843bb2c54869f66913b422daa4df1faa0a2ec1a1d7a2f

I don't see those two methods (maintain access to identical copies of orphaned artifacts, maybe substitute compatible artifacts) as in competition at all personally I think both methods are clever and will be useful and I'd like to have both be possible. For the "reproducible build" crowd they'll want SHAs to match up with the original artifacts on whatever code they can't change without re-qualifying I think, so both ideas have room in any solution

[d4vidi]

@mikehardy I'm familiar with the approach and have even utilized it in the context of the com.facebook.fbjni:fbjni-java-only artifact, due to dep discrepancies of versions 0.0.3 vs. 0.0.4 (it is indirectly required by RN itself).

The technique is perfectly valid for artifacts that are both hosted and which hosted version plays well with the depending libraries, in terms of compatibility. However, this isn't always the case, as we've seen with respect to com.facebook.yoga:proguard-annotation, which doesn't seem to be hosted anywhere. For that, you are forced to host the artifacts elsewhere, and this is where you suggestion comes in to play as everyone's life saver.

[mikehardy]

Yeah I see it as one trick in a bag of tricks. Finally got enough react native firebase stuff off the queue last week I should be able to do a poc today 🤞

[mikehardy]

While doing some research on this, this morning, I re-checked and saw this:

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.

https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/

So as far as I am concerned this is resolved -> wontfix, though I have ideas posted up in my repo if needed.

[kelset]

We listened to the community and will keep JCenter as a read-only repository indefinitely.

Oh wow that's huge. Yeah I guess we can close this one off since it won't need an actual fix ever, then :D

[dmoebius]

JCenter will be put into read-only mode. Where will you publish updates?

[kelset]

@dmoebius I'm not sure what you are referring to; the only package that is "stuck" in the JCenter limbo is org.jetbrains.trove4j:trove4j and that's already an unmaintained package, so there have not been updates to it in a very long time.

[raydenvoldeskine]

I had RN 0.64.x and start getting this error today. I have updated RN to 0.65 as advised in this thread, even removed node_modules before but I still get this message!

Unable to load Maven meta-data from https://jcenter.bintray.com/com/facebook/react/react-native/maven-metadata.xml.

[alex-a-pereira]

@raydenvoldeskine not exactly sure but it looks like bintray went down earlier.. even their status page is 502'ing.

If you try to go to that URL that it's trying to fetch meta-data from it 502's as well

[raydenvoldeskine]

Yes I did that. And I hoped from that thread RN 0.65 solves the issue but the problem is still there for me
And also I cannot find any entry of "jcenter" or "bintray" in node_modules, do not currently get where it is coming from.

[mikehardy]

Ugh, looks like bintray is still supposed to be up but I confirm this as well. Appears to be an unexpected outage, separate from their sunset (which was changed to just "sunset on uploading new packages, but we'll keep resolving old ones". Hopefully it comes up soon, react-native-macos currently only goes as high as react-native 0.64 😩 and I was working on a netinfo macos example

[HadiModarres]

Wasn't RN 0.65 supposed to be not dependent on jcenter anymore? So why does jcenter outage still affect the builds?

[mikehardy]

Good question. Perhaps people did not remove it from their builds? I still have it in mine because I have one stubborn lib that needs it. npx react-native init TestProject followed by cd TestProject && npx react-native run-android will likely work, even if you add --version=0.65.0 to the init line, according to upgrade-helper: https://react-native-community.github.io/upgrade-helper/?from=0.64.2&to=0.65.0

I'm just stuck because work projects have one stubborn lib, and library side-task requires 0.64. No winning here. Hopefully it comes up soon.

[raydenvoldeskine]

I assume in my case the reason was a native module which included jcenter() reference (react-native-zebra-scanner), the module hasnt been updated for three years, so no surprise.

[radko93]

Expo still includes jcenter in some projects like expo-av or image picker.

[laerciokonzen]

This are my changes on the android/build.gradle to make it work. But it`s taking around 10 times more to get the build done.
Any insight?

buildscript {
    ....
    repositories {
        google()
        mavenCentral()
        mavenLocal()
    }
    ....
}
....
allprojects {
    repositories {
        maven { url "https://plugins.gradle.org/m2/" }
        maven { url "https://repo.spring.io/plugins-release/" }
        mavenLocal()
        ....
        ....
        mavenCentral {
            // We don't want to fetch react-native from Maven Central as there are
            // older versions over there.
            content {
                excludeGroup "com.facebook.react"
            }
        }
        ....
        ....
    }
}

[mikehardy]

Standard insight for network related things: You've added a new remote end point that gradle consults for each dependency. That new endpoint must be slow.

bintray is back though, so at least until we're all using good dependencies, we're good again for a while.

If you're using dependencies that are unmaintained and not moved off bintray, fork them, and do the work needed to get them published correctly off jitpack, and you'll be able to move on as well (for example: https://github.com/hieuvp/react-native-fingerprint-scanner/pull/189/files)

[cortinico]

Any insight?

@laerciokonzen You definitely don't need the first two lines. The first is the Gradle Plugin Portal where only Gradle Plugins are hosted, not runtime dependency (hence is not needed). The second is the a Spring Maven Repo, which I also believe is not needed in your specific case (unless you're using some Spring library that is not on Maven Central).

Anyway as the Bintray outage is over, you should be all good by now.

[cortinico]

Wasn't RN 0.65 supposed to be not dependent on jcenter anymore? So why does jcenter outage still affect the builds?

Dropping a couple of clarification point here as there was a lot of confusion in the last days.

That's a link to the incident report on Gradle's end: https://status.gradle.com/incidents/nv93msj8q658

As @HadiModarres asked, RN 0.65 is not dependent on JCenter anymore. However, this outage of Bintray/JCenter was affecting the ecosystem in a number of way:

• Expo SDK was based on RN 0.64.x, hence still used jcenter() definition in their build.gradle files
• Libraries that you import via autolinking are importing build.gradle files that live inside the node_modules folder inside your build. Should those file contain a jcenter() definition, as maybe the library author hasn't updated them, you'll be hitting JCenter for that specific library.
• If you're using Gradle Portal (i.e. you have a plugins{} block, or you have a maven { url "https://plugins.gradle.org/m2/" } or a gradlePluginsPortal() defined in your repositories{} block), you would have not be able to build. This because Gradle Portal is mirroring JCenter. More on this here:
  • Add option for Gradle Plugin Repository to NOT redirect to JCenter as they regularly rewrite POMs and break checksums gradle/gradle#15406

Specifically, @ShikaSD pushed a fix that mitigated this last point yesterday facebook/react-native@3cf0291

That being said, the suggestion is to try to keep your RN version up-to-date as you won't benefit of some of the improvements we pushed if you're missing out on versions.

EDIT: typo

[raydenvoldeskine]

Is it me or Error 502 is happening again right now?

[walesonn]

Yes, It's happen with me too

[FrSenpai]

Yes, It's happen with me too

Same today, sadly ... Need to stop to use jcenter and switch to Maven, but ... meh... so many projects impacted :(

[salman1696]

adding this to build.gradle works for me.
gradlePluginPortal()

[emrecanozkok]

adding this to build.gradle works for me. gradlePluginPortal()

explain please where you added

edit:anyway i added it and my problem seems fixed

edit2: not fixed :)

[salman1696]

adding this to build.gradle works for me. gradlePluginPortal()

explain please where you added

edit:anyway i added it and my problem seems fixed

edit2: not fixed :)

[cortinico]

An update for those users still on Expo SDK 44 which depends on RN 0.64.0. We now re-uploaded some artifacts that were previously only on JCenter to MavenCentral:

com.facebook.yoga:proguard-annotations:1.14.1
com.facebook.fbjni:fbjni-java-only:0.0.3
com.facebook.flipper:flipper:0.54.0
com.facebook.flipper:flipper-network-plugin:0.54.0
com.facebook.flipper:flipper-fresco-plugin:0.54.0

That should mitigate some of your build failures, as those artifacts can be found also on mavenCentral now. JCenter was down a couple of times last week, and I won't be surprised if this were to happen again.