You probably have heard that JFrog, the company behind Bintray and JCenter, is shutting down these (mostly free) services soon. Whether you're the author or a user of any of the nearly 800,000 libraries that are exclusively available on JCenter, you're probably wondering what's going on and how to deal with this.
As a result of JCenter and Bintray shutting down, many library authors who published their libraries to JCenter with entirely made up groupIds now face a very painful migration to Maven Central, having to also pick a new groupId which they can assert they control. Contrary to JCenter, Maven Central requires you to "control" the groupId you publish under. In other words, this means you need to control the corresponding domain, obtained by reversing the groupId. We'll see this in more detail later in the article.
When to act?
Luckily, JFrog decided to relax the extremely narrow sunsetting timeframe they had initially chosen. Instead of making JCenter and Bintray read-only at the end of February 2021 (the same month they announced the sunsetting), and completing the shutdown on May 1st 2021, they've now postponed those deadlines. JCenter will not accept submissions starting March 31st 2021, and Bintray will do the same starting May 1st 2021. Lastly, from February 1st 2022, JCenter will shut down entirely.
Library authors and consumers alike will have some time to get themselves migrated to Central, although one can be quite sure many will wait until the last minute to do so. I kind of expect some panic as we get closer. I recommend you avoid that panic by starting to prepare now...
How badly am I affected?
If you do have JCenter declared in your repositories block, it's a good idea to take stock of your current situation. Figuring out what dependencies will go boom in a year's time is fairly easy. Remove the jcenter() entry from your build.gradle(.kts) scripts, and run a build using the --refresh-dependencies flag:
$ ./gradlew assemble --refresh-dependencies
[...]
BUILD FAILEDAssuming the build worked before removing JCenter, Gradle will fail and list all the now unresolved dependencies, meaning the ones that are only available on JCenter. At that point, you should go check whether all those dependencies are in the process of migrating elsewhere, such as to Maven Central, and prepare to update your build scripts accordingly.
If you use a library, and the authors don't plan to move it somewhere safe or don't respond at all, you have a few options. In order of my personal preference:
- Use a different library that is not abandoned — may be a good opportunity to migrate and reduce your tech debt. Using abandoned software may lead to all sorts of headaches down the line, including security issues.
- Set up a Maven repository of your own and host a copy there — both Artifactory and Nexus can be set up to act as proxies. It can be a complicated process and it is outside the scope of this post.
- If everything else fails, grab the jar/aar file from JCenter while it still exists, put it in your project — say, in a folder called
/lib— and addimplementation(fileTree("lib"))to your dependencies block. This is really the last resort, the other options are much preferable.
What if I am a library author?
If you're a library author, you should really consider uploading your library to Maven Central. While there are some alternatives, such as Jitpack, the only real solution is to move to Central — and change your groupId, if necessary.
While JCenter has almost no rules on who can upload what, Maven Central has a more stringent set of requirements, mostly to avoid squatting and impersonation. This reduces the risk of malicious actors pulling off supply chain attacks, which are a serious threat in any ecosystem.
The main requirement for Maven Central is that you need to own your groupId – that is, proving you control the domain that the groupId represents. So, for example, if your library on JCenter has the coordinates com.fancybanana:banana-peel, but you don't own fancybanana.com, you need to change your groupId to some domain you actually own. When registering a new groupId on Maven Central through Sonatype, they'll check that you can put some special value in the domain DNS records, by adding a special TXT entry. The process is largely automated and can take anywhere from a few minutes to a few hours.
If you need to change the groupId, remember that you can also use something like com.github.[your github userID] or io.github.[your github userID] if you don't want to purchase a domain, as long as the user ID matches the one you have on GitHub. You can find the full list of Maven Central requirements here, and the details of how to use a GitHub-based groupId here.
If you need help, you can refer to Martin Bonnin's article which goes into good detail on the process to follow:
He's also just published a tool, Vespene, to help automate the transition as much as possible. You should check that out, too!
You’ll likely go through some pain to get your library on Central, but it is a one-off affair and a very good investment, if you do it as soon as possible.
Thanks to Daniele Conti, Florian Mierzejewski, Jon Reeve, Mark Allison, Martin Bonnin, Rui Teixeira, and Sebastiano Gottardo for their feedback and help with proofreading ❤️