404 Not Found error

Question

My build suddenly stopped working recently, and now is giving me an issue with 404 Not Found for a URL on https://repo1.maven.org. Why did this happen, and how can I fix it?

Answer

If your build previously worked and is no longer working, you are likely seeing this error due to the sunset of JCenter and the redirect of requests from JCenter to Maven Central. For libraries that were published to both repositories, your builds should continue to work as expected. However, for any libraries in your project's dependencies that existed on JCenter and not on Central, you will encounter this error.

There are a number of approaches you can take in order to fix it. Firstly, we would recommend removing the JCenter repository from your project's configured list of repositories, and adding Maven Central if it is not already present. There is not an end-date for how long JCenter will redirect to Central, but making the change now will avoid further disruption.

• Maven Documentation
• Gradle Documentation

See if there is a newer version or an alternative library

Since JCenter's initial announcement in 2021, the service has been in a read-only state. That means that any library you depend on from JCenter is multiple years out of date. While we strongly support the immutability of software repositories to ensure projects are able to build on a foundation that is trustworthy and will stand the test of time, we also recognize the value of updating dependencies when new security vulnerabilities are identified and addressed or when significant bugs are fixed. Some publishers have migrated to publishing via Central, but have not re-released the previous versions of their libraries.

The quickest way to get your build working again is likely to be looking for a more recent version of the same library or a library that performs the same functionality.

Request that the library author publish to Maven Central

If the library has not been published to Central at all, you could consider locating the project's issue tracker or mailing list and submitting a request for them to publish to Maven Central.

If you are going to take this approach, we would appreciate if you keep in mind that publishers are providing you a free service. They are under no obligation to publish their library the way that you want at the location that you want. They may have already considered publishing to Maven Central and decided on a different approach. Please check their documentation to see if they have provided a more recent way of consuming their packages before making your request. As operators of a free, community service ourselves, we would hope that you make your request in a kind manner. We do not wish to give publishers a negative experience with Central.

If you have done all that and still wish to proceed, we suggest you include the following context:

• JCenter's sunset announcement that suggests publishers switch to publishing via Maven Central
• Maven Central's publisher documentation, which should be the most accurate, up-to-date way to publish.
• A note that Maven Central will require some form of proof that the user published with JCenter, which will likely involve signing a file with the same PGP key that was used to publish an artifact on JCenter

Vendor or fork the library

If the publisher is no longer active, you may need to take ownership of the library in order to keep using it. If you are able to find the source repository, you should be able to build it locally at the same commit as the version of your dependency. The specific commit can commonly be identified through the use of git tags or similar features.

This is likely the approach that requires the most effort. For the smoothest experience, you would want to run an instance of a repository host like Sonatype Nexus Repository Manager that would allow you to host your vendored dependencies alongside a proxied copy of the dependencies available on Central.

If you choose the approach of forking the library, you are allowed to publish your copy to Maven Central as long as you comply with the license terms. We would suggest changing the name of the library and removing any trademarked terms that could be considered as misrepresenting your fork as the original library.