JFrog has announced that they are shutting down the Bintray hosting service, which includes the popular JCenter hosting service for Java artifacts, as well as GoCenter (which hosted Go packages) and ChartCenter (which hosted Helm charts). In the message, Stephen Chin, VP of developer relations at JFrog, writes:
Bintray has provided the open source community a free, universal cloud platform for publishing and distributing binaries. Bintray helped JFrog support the Java community as the host of the JCenter repository for Java OSS libraries, packages and components. We launched GoCenter and ChartCenter to extend similar services to the Go and cloud-native communities.
JFrog is evolving to meet the new challenges that developers face. Many of the services that Bintray provides are now served by the JFrog Platform for the open source community. Similarly, the Go and Helm communities have since created central repositories of their own that are drop-in replacements for our centers.
To streamline the productivity of the JFrog Platform we will be sunsetting Bintray (including JCenter), GoCenter, and ChartCenter services on May 1st, 2021. Users of these services will need to migrate to the respective canonical repository, and we will continue to offer both free and paid JFrog Platform cloud subscriptions that can serve other binary distribution needs. Additionally, JFrog is partnering with hubs like Docker to help ensure that infrastructure our customers and community depend upon is well maintained.
JCenter rose to prominence as a lighter-weight solution for publishing Java assets with less friction than Sonatype's hosting of Maven central. However, the anything-goes nature of JCenter meant that some assets legitimately published to Maven Central were copied to JCenter and introduced malicious behaviour along the way. One such example was written up in an incident response in which a set of modified binary assets were uploaded to the same co-ordinates as in Maven central; depending on which repository was configured first in an application's build path would pick up either the known good or bad version.
Perhaps the biggest growth of JCenter occurred when Gradle made JCenter the default repository in its documentation and examples, such as the sample gradle plugin which suggests using jcenter() as the default:
repositories {
// Use jcenter for resolving dependencies.
// You can declare any Maven/Ivy/file repository here.
jcenter()
}
In addition, new Android studio projects did (or still do) the same: following the gradle dependency guidelines:
allprojects {
repositories {
google()
jcenter()
}
}
Bazel projects also encouraged the use of jcenter above Maven central:
maven_install(
artifacts = [
"com.google.code.findbugs:jsr305:1.3.9",
"com.google.errorprone:error_prone_annotations:2.0.18",
"com.google.j2objc:j2objc-annotations:1.1",
],
repositories = [
"https://jcenter.bintray.com/",
"https://repo1.maven.org/maven2",
],
)
What should you do
If you have any Java, Gradle, Bazel or Maven builds that use jcenter() or jcenter.bintray.com, you need to ensure they will build correctly after having removed the references from the build.gradle or settings.xml files respectively. (If you're still building with Ant or Ivy, you need to upgrade to a more modern build tool.) You might also need to verify that the builds will be successful if you are using caching proxies; it may be that although it builds on a clean environment for your local machine, it could still be sourcing cached assets from an intermediary cache.
If you operate a proxy that has previously forwarded to JCenter, it might be advisable to switch it over to just point at Maven Central and then let the proxy cache re-fill itself. You'll then be able to identify what assets you depend on that aren't in Maven central and take corrective action to remediate. (You should rename the repository cache rather than delete it, in case anything is needed that can't be resourced again.) You might find that the hashes of the assets have changed in case there are malicious assets you have inadvertently depended upon before.
It's quite likely that a non-trivial number of dependencies will be present in JCenter but not in Maven Central, as over time some developers have opted for a lower-effort publishing mechanism. In addition, some issues with uploading assets to Maven Central back in the 2000s might have put off some users historically, but there hasn't been any significant issues with uploading to Maven Central for over a decade, and in any case, the upload and filtering mechanism is the input to a globally distributed cache of assets that's served independently of the upload mechanism, and can be accessed via repo.maven.apache.org and Google's hosted maven-central.storage.googleapis.com.
Due to the Gradle (and thus Android) build tools encouraging the use of JCenter, it's likely that there will be more impact to those using those build tools or operating systems rather than those who just use stock Maven builds or repositories.
Bintray and its hosted repositories will be read-only for new updates from the end of this month, and will be shut down at the end of April. Although there may be a mechanism to retrieve assets in the immediate aftermath of the shutdown, it's possible that JFrog will charge for such access -- and there's no guarantee that the assets will be available much more than a couple of weeks afterwards. [Update 8th Feb: as per the update below, assets will continue to be served until end of Jan 2022.]
JFrog provides the asset manager Artifactory, and says that users of its products who have support contracts will be unaffected by the closure, so it may be that while the public front end is going away, it may be available for paid consumption behind their products. Those who use other asset managers will not have such preferential access, and so if you are using other build tools or proxies, then remediating or replacing dependencies is recommended.
Migrating to Maven Central
Brian Fox, CTO of Sonatype (who runs Maven central) offered some suggestions (and subsequently blogged about it) for those who had previously chosen to publish assets to JCenter:
If you’re freaking out because of the Bintray / jcenter announcement and need to get your Java components into Maven Central, don’t worry, we’ve got you. Here are a few things to know:
Lots of less visible improvements have been put in place since you probably deployed to http://oss.sonatype.org years ago. The validation and onboarding process has been automated, making the approval of your coordinates happen much faster and in many cases, automatically.
Yes, we do still validate coordinates. This has always been the case for what, 16 years or so, and that isn't going to change. Validation of coordinates is the way that we ensure people can't (as easily) pretend to be a project they are not. I recently wrote about that here: https://blog.sonatype.com/malware-removed-from-maven-central
If you were previously deploying to Bintray and still promoting to Central, you have already been configured in our system so you should have what you need to begin deploying directly. If you're not sure though, create a ticket and we'll help you out.
If you were previously deploying to Bintray and -not- promoting to Central, then we will have to get you setup, and figuring out how to handle your coordinates is going to be a conversation. For those long standing requirements, you can see here: https://central.sonatype.org/pages/choosing-your-coordinates.html
And with all of this, we are here to help, if you're confused or struggling, just ask. If you think the coordinate requirements won't work for your project, let's discuss and try to figure it out. Tweet me if you want, or @sonatype_ossrh or create a ticket at the above Jira.
One last thing, if you are deploying to Central and want to see security analysis of your project dependencies, we've been working on that too. Hit me up and I'll share what we have with you preview style. We were just about to launch an Alpha program, so YOLO, here it is.
Of course, not everyone who has published to JCenter over the last decade still maintains their projects, or even continues to work in the open source software industry, and so may not be able to migrate their original codebase over. Statistically, it's also likely that several original authors or publishers of software have passed on. Even though it's possible, it's potentially unlikely that all dependencies will be moved over, so unless some other oganisation volunteers to maintain a backward mirror, there's a chance some software will be lost for ever.
Update 8th Feb
JFrog have released an update to their original blog post to clarify that the date has been extended:
UPDATE: To better support the community in this migration, JFrog has extended the JCenter new package versions submission deadline through March 31st 2021.
To clarify, the JCenter repository will keep serving packages for 12 months until February 1st 2022. Only the JCenter REST API and UI will be sunsetted on May 1st 2021.
(You may have to refresh the post if since it may have been cached by your browser since you last visted in order to see the update.)
How will you be affected by the closure of JCenter and Bintray? Let us know in the comments.