Resources Blog What publishers need to know about migrating from JCenter / ...

What publishers need to know about migrating from JCenter / Bintray to the Central Repository

We know the news about JFrog sunsetting Bintray/JCenter has been unsettling for many. Our goal is to make the migration to the Central Repository as easy as possible - whether you're just consuming components or if you're publishing them as well. You can also read more about our commitment to Central in a recent blog post by Sonatype Co-Founder and Maven grandee Brian Fox.

In this article, we're talking specifically about what publishers need to know as they migrate. Any migration is going to have its friction, especially with such strict timelines as JCenter's shutdown schedule. Let's face it, moving off a platform in less than six months is going to be a serious challenge to most organizations. Still, we'd wager it's easier than you think.

There are a ton of great guides to help you with this if you prefer reading external blogs. Check out the below for some great tips. As these migrations mostly affect Android and Gradle, you can find some great material on those below as well as a comprehensive maven guide.

The main avenue for publishing into The Central Repository is via a service known as Sonatype OSSRH (OSS Repository Hosting)- OSSRH uses the Maven repository format and allows you to:

  • deploy development version binaries (snapshots)
  • stage release binaries
  • promote release binaries and sync them to the Central Repository

The difference between publishing to JCenter via Bintray vs OSSRH is most evident in the initial setup for your OSSRH repository, as the process requires some manual one-time steps and one-time review on our side.

The reason for the above is Central is committed to protecting the integrity of projects published to it. As key infrastructure, Central is often a target for software supply chain attacks such as coordinate spoofing or brandjacking. To protect the integrity of the name space, we conduct a manual initial review. Once these initial steps have been completed publishing is completely automated and happens quickly.

As a commercial product, the Bintray / JCenter user experience was designed to be friendly to developers. We acknowledge that migrating over to using the OSSRH process will have some friction involved especially when getting set up.

To get started migrating your project into Central, you can follow along the OSSRH guide here:

You can also follow the abridged guide below.

Step 1 - Sign up to OSSRH Jira and claim a namespace for your project

If you're a Bintray customer who published to central via Bintray, you're most likely covered. You can just go right ahead and begin the next step. If not, read below on how to get signed up.

The speed of the OSSRH registration process

As with any service that deals with 10s of thousands of components being published every day, we experience fluctuations in service quality, and do our best to maintain this channel for the community.

We are committing to responding to onboarding new projects with a maximum SLA of two business days, but most processes are completed in a matter of a few hours. We are placing extra attention to help the community clear the migration process as quickly as possible.

To speed up this migration as fast as we can, we recommend you open a ticket with us should you encounter any issues. We are placing extra scrutiny on projects wanting to migrate over from JCenter.

Step 2 - Check your project complies with the Central requirements

The next step is making sure your project has all the necessary metadata and is signed. If you were already promoting to central from Bintray you should be all set.

Central requirements

As primary infrastructure, the Central Repository places some requirements on the artifacts published to ensure the quality and integrity of the components. These requirements are roughly:

  • Supply Javadoc and sources
  • Sign your files with GPG/PGP
  • Sufficient and correct metadata for your projects

The complete list of requirements can be found here:

Although the steps may seem steep to begin with, they're one-time activities that will be easy to clear after your initial publish. The most common point of friction is GPG / PGP key management. Bintray automated many of these steps. There is a detailed guide available to help you get started with GnuPG here:

We recommend investigating key management services such as or AWS Key Management service or any other Secrets manager to help you streamline storing your signature keys.

Step 3 - Publish your stuff to OSSRH to prep it for release

If you prefer skipping straight to the docs here they are. You can use the many ways in your native tools to do it, or one of the great community approaches to achieve this. Depending on your choice of tools and approach there are many different ways to do this.

Note: There is a limit of roughly 1024MB on any single file uploaded to OSSRH. Your uploads will fail with a broken pipe exception when you hit this limit. Contact us directly if you need to upload larger component.

Opening these repositories we will perform a completeness check on the metadata, presence of sources. At this point, you can either use the delightfully rustic web interface, or proceed through a CLI interface.

Step 4 - Release to Central

At this point, your project is deployed to a private repository only accessible to your project members.

To release your components, you can either release them directly from the command line, if you are using the Nexus Staging Maven Plugin or Ant Tasks or open your favorite browser and go to or follow our detailed instructions.

Step 5 - Automate releases

Once you're live -  you can just automate the above steps using either Maven Staging, Gradle or the starship or any number of other means to do this.


You can use the maven-staging-plugin to completely and easily automate the staging process in OSSRH. Doing this is easy - just add it as a plugin in your pom.xml and you're good to go.

To configure it simply add the plugin to your Maven pom.xml.















If your version is a release version (does not end in -SNAPSHOT) and with this setup in place, you can run a deployment to OSSRH and an automated release to the Central Repository with the usual:

mvn clean deploy

With the property autoReleaseAfterClose set to false you can manually inspect the staging repository in the Nexus Repository Manager and trigger a release of the staging repository later with

mvn nexus-staging:release

If you find something went wrong you can drop the staging repository with

mvn nexus-staging:drop

Read the full guide here


Startship is a community project by Saket Narayan ( that allows you to do all steps via a CLI that runs in your terminal. It’s useful if you are not a maven user.

Getting help with the OSSRH Process

Should you encounter any issues with the above, feel free to open a ticket in our JIRA issue tracker or reach out directly to us at @sonatype_ossrh and @sonatypedev on twitter. We are happy to jump in and help when needed.

Happy sailing

Sonatype remains committed to supporting the java development community with continued service of the Central Repository. We look forward to helping projects that wish to do so migrate over and help them get the wind in their sails to continue helping their users in part.

Picture of Ilkka Turunen

Written by Ilkka Turunen

Ilkka serves as Field CTO at Sonatype. He is a software engineer with a knack for rapid web-development and cloud computing and with technical experience on multiple levels of the XaaS cake. Ilkka is interested in anything and everything, always striving to learn any relevant skills that help towards building Sonatype for success.