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 developersnow 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 Gradlecaches. 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 thatworked 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 retrieveartifacts on every build might have found out within a day of the JCenter shutdown. Those usingjust local build machines might not find out for years, depending on how long they keep theirGradle 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 ofthese libraries were developed in the open in places like GitHub. See if that site has instructionsfor some newer maintained version, and migrate to it. Conversely, if the library has not beenupdate in years, please consider moving to something that is actively maintained.

You could also search MvnRepository. This is an index of severaldifferent artifact repositories, including Maven Central and Google���s Maven repository. It used toindex JCenter, and it also has some other less-common Maven repositories. Perhaps you will findanother source for the particular artifact that you need. However, be careful when dependingon a semi-random library from an even more random repository ��� you are asking to becomethe victim of a supply-chain attack.

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

Going forward, aim to do a clean build on a clean environment periodically. Even if you do notelect to go for a nightly CI server job, do a build once a month on an environment that lacksa 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.