The Central Repository stands to support sailors from Bintray - three steps to take now to protect your builds from failing

February 08, 2021 By Ilkka Turunen

8 minute read time

The shutdown of Bintray and JCenter comes as a rough entry in the 2021 Bingo card for many developers - most Android projects as well as Gradle and many others publish their artifacts via Bintray into JCenter. The migration timelines are tight for both consumers and producers of artifacts - Bintray will stop accepting submissions at the end of February 2021, and the entire service will shut its lights on May 1, 2021.

As custodians of the Central Repository, we here at Sonatype understand the monumental effort that can go into maintaining a safe, reliable and robust open source ecosystem.

We want to assure the community that Sonatype's commitment to maintaining Central remains strong, and we are taking steps to ensure the projects that wish to migrate over from Bintray are supported.

This article is a practical guide on the steps you can take to ensure that your use and distribution of open source components continues smoothly. To learn more about our commitment to the users and publishers of the Central Repository read the recent blog post by Sonatype Co-Founder and Maven grandee Brian Fox.

Many projects that are available via JCenter have been mirrored from Central, and so for many the process should be a matter of changing repositories in configs. The steps outlined will be useful similarly for developers in Go using GoCenter or Helm users using ChartCentral.

Developers and consumers - three step plan 

As a consumer, you have to change your configuration to use Central or other authority instead of JCenter. Most artifacts available through JCenter were actually mirrored from the Central Repository - so in many cases the migration will be a drop-in replacement by updating your build configuration. Similarly, Go and Helm now have official sources JFrog is advising you to migrate to.

The three-step plan you should follow as a consumer of open source is set below:

  1. NOW: Set up a proxy repository to cache your components.
  2. Test for component availability.
  3. Finalise your migration.

1. Set up a proxy repository to cache your components

One of the main concerns on May 1, 2021, will be the ongoing availability of the artifacts exclusively hosted in JCenter as JFrog have offered up no plan to migrate or archive the contents to the public. To combat this very imminent issue of missing artifacts affecting your builds on May 1, 2021, you should set up a proxy repository to JCenter which will store copies of what you are using - ensuring what you need is cached in your repository.

The easiest way to do so, is to use Nexus repository manager OSS. It comes set up with everything you need - just create a new proxy repository to JCenter and add it to the built-in group maven-public. Instructions on how to do this can be found here:

Java - use the Central Repository

As mentioned, most Java users will find the Central Repository their best port of call. The good news is all major artifact repositories come set up with Central connections out of the box. Getting a proxy to JCenter now and creating a group repository will help you cache what you need for the cutover.

Go - use Go Dev

The recommended location to discover packages after GoCenter is shut down is https://pkg.go.dev . There are a number of public athens servers that help you download components easier - for example https://gonexus.dev/.

We recommend using group and proxy repositories similarly to Java to centralise the access to these new locations.

Helm - use ArtifactHub

Helm users will need to configure entirely new locations for their artifacts. The accepted community destination is https://artifacthub.io/ from the CNCF. Artifact hub can be proxied using Nexus Repository manager easily.

All tooling - changing configuration to use your new proxy and group

If you did the above steps, when the time comes for JCenter/GoCenter/ChartCenter to go offline you'll have stored copies of all you need to continue building. This also helps your developers experience, as they won't have to change the configuration once the switchover happens. See below how to configure tooling to use your new proxies.

Gradle, Kotlin and Android users

In your build.gradle repositories section needs to be updated in line with the examples from the gradle documentation:

https://docs.gradle.org/current/userguide/dependency_management.html#sec:repositories

repositories {
    mavenCentral()
}

We however recommend using a group repository to proxy all required sources - for example by using Sonatype Nexus Repository Manager OSS. To configure a connection to a proxy repository you may use the following snippet:

repositories {

    maven {

        url  "https://nexus-repository.internal/repository/maven-public/"

    }

}

 

Bazel users

Make sure your WORKSPACE file has a maven central entry or a entry pointing to an artifact repository in the maven_install section:

https://docs.bazel.build/versions/master/migrate-maven.html#guava-project-example-external-dependencies

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://nexus-repository.internal/repository/maven-public/",

        "https://repo1.maven.org/maven2",

    ],

)

SBT users

You should search for the built-in JCenter resolver and replace all entries to point to Central. See SBT documentation for more information:

https://www.scala-sbt.org/1.x/docs/Resolvers.html

Maven users

Maven comes pre-configured with a Central connection in settings.xml and you most likely will already have the connection configured. If you have removed it, the repository connections are set in the repositories section.

Go developers - using GOPROXY

Proxying from go is less straightforward versus other languages. Fundamentally this relies on updating $GOPROXY as a developer to point to your newly created go Proxy.

Helm users - add new repository

Helm users will need to change their helm repository config with the helm command to add the new repository address in place.

 

helm repo add <helm_repository_name> http://<host>:<port>/repository/<nexus_repository_name>/ --username <username> --password <password>

 

JFrog Artifactory self-hosted users

JFrog have stated that users of their self-hosted repositories that connect to GoCenter, JCenter or ChartCenter should update their remote repositories to use canonical sources. https://www.jfrog.com/confluence/display/JFROG/Repository+Management

2. Test Availability & Raise Migration tickets

Once you have connectivity set up, you should test your builds without JCenter availability by temporarily removing it from the group, This will help you to identify what components you have that are currently JCenter exclusives - and what you'll need keep cached.

From an industry perspective, as custodians of Maven Central Sonatype is investing in helping projects migrate over from Bintray as soon as possible, but we cannot guarantee all will make the cut. Should you identify as project you'll need you should reach out to them to understand what their future destination will be.

3. Finalise migration

Once all the artifacts you need have migrated over to Central and your build clears, you are sailing in smooth waters once again. With Repository in place your experience should be close to seamless. You can now finalize your transition and enjoy calm weather once more.

Tags: The Central Repository, featured, Product, Community Product, DevZone

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.