Why external repos are being phased out of Central

March 24, 2010 By Brian Fox

8 minute read time

We recently started raising the minimum criteria for artifacts coming into Central:

  • Blind rsync transfers of random repositories are no longer being added and will be phased out over time
  • All artifacts must be properly signed with GPG signatures that are publicly verifiable
  • sources and javadocs must be included
  • scm urls must be included
  • No external repository definitions

That last one seems to cause the most commotion for users that depend on artifacts not currently in Central and I wanted to take this opportunity to show why this is being done.

The urls you see below are listed as RELEASE repositories found in the poms of a prominent repo we're attempting to clean for syncing to Central. In the list below you will find some interesting bits:

  • file based urls
  • urls with private ip subnets
  • snapshot repositories (remember this is a list of the RELEASE repos only according to the poms
  • Links to websites (like [http://maven.apache.org]) or wikis
  • Many sites that no longer exist
  • Repositories that are actually mirrors of Central (Ibiblio)
  • Repositories who's contents are already in Central (codehaus)

Of the few repositories that actually do still work, many of them have what I would call "garbage" in them. I'll define garbage here as things that didn't originate from this project and are either hacked/patched versions and/or duplicates of artifacts that are found somewhere else.

When you start blindly using these repos, best case you could get artifacts who's provenance is suspect and your builds are slowed down because Maven is sent off on a wild goose chase. Worst case, you still have to find these repos by hand and override the bad urls.

In the list below, I think my favorite is the dynamic search of a Fisheye repository at Atlassian.com. I'm sure they love having thousands of builds doing automated searches of their Fisheye service looking for every artifact in a build.

When we sync these poms to Central, it is highly likely we will simply ditch all of these references. We don't take changing poms likely, but in this case it is clearly the lesser of two evils. Having the ability to leverage artifacts in some other repo is a nice fix in the moment, but once you release your project this way, you forever become a slave to that project maintaining the repo.

In order to improve the experience for everyone, we are working to block this from happening in Central. We have several efforts underway to help minimize this impact, and that primarily includes making it easier to get your artifacts and third party artifacts into Central. Stay tuned for more exciting announcements on this topic.

Tags: Sonatype Says

Written by Brian Fox

Brian Fox is a software developer, innovator and entrepreneur. He is an active contributor within the open source development community, most prominently as a member of the Apache Software Foundation and former Chair of the Apache Maven project. As the CTO and co-founder of Sonatype, he is focused on building a platform for developers and DevOps professionals to build high-quality, secure applications with open source components.