Hey, Where Did My Artifacts Go?

We are getting a lot of questions like this one, of the form:

My builds are now failing because some of my dependencies cannot be found. Where did they go?

While there can be a few causes for this, the one that is tripping up a lot of developers now stems from the fact that JCenter’s Maven repository, used by many library publishers, no longer exists.

For actively-published libraries, the library developers would have moved elsewhere by now. For many developers, the best answer would be Maven Central, though some have other options. Google, for example, has the latest version of Volley available through their own Maven repository.

However, there are a lot of not-actively-published libraries. Those are probably gone for good.

The reason the JCenter change is not affecting everyone at the same time comes down to Gradle caches. Gradle caches artifacts and only tries downloading them when needed, such as:

• You add a new library dependency
• You change the version of a dependency that you want to use
• Your Gradle artifact cache gets cleared
• You try building on a new machine than where you had been before

Those latter two probably are the ones that cause the most JCenter-related grief. Some build that worked before and perhaps works elsewhere (e.g., on a coworker’s machine) does not work for you, because “elsewhere” has the artifact cached and you do not. Teams using CI servers that retrieve artifacts on every build might have found out within a day of the JCenter shutdown. Those using just local build machines might not find out for years, depending on how long they keep their Gradle artifact cache around.

So, what do you do if you get caught by this?

First, search “teh interwebs” for the library to see if there is a site regarding it. Many of these libraries were developed in the open in places like GitHub. See if that site has instructions for some newer maintained version, and migrate to it. Conversely, if the library has not been update in years, please consider moving to something that is actively maintained.

You could also search MvnRepository. This is an index of several different artifact repositories, including Maven Central and Google’s Maven repository. It used to index JCenter, and it also has some other less-common Maven repositories. Perhaps you will find another source for the particular artifact that you need. However, be careful when depending on a semi-random library from an even more random repository — you are asking to become the victim of a supply-chain attack.

If the source is available on GitHub or elsewhere, you could fork the source and maintain your own copy. Whether you make that available to the public (e.g., on Maven Central) or just share it with your team is up to you. Maven Local is a quick-and-dirty way to have a Maven repository on your machine for artifacts. Setting up a private shared repository, such as via Amazon S3, is eminently doable, if slightly arcane.

Going forward, aim to do a clean build on a clean environment periodically. Even if you do not elect to go for a nightly CI server job, do a build once a month on an environment that lacks a Gradle cache. Part of the value in those builds is to more rapidly identify problems like this, so you can take steps before the problem starts affecting the productivity of individual developers.