maven dependency report: avoid delay and error messages for (glassfish) repository

Question

When I run the site build of Apache Commons VFS2 the dependency-report plugin tries to fill a matrix, which artifact can be obtained by which repository.

In my case it also tries to inspect the maven.glassfish.org repository, which is AFAIK abandoned. But since it is still on some of the used dependency POMs, it is still showing up in my project (and I guess I cant influence that easily).

[INFO] Generating "Dependencies" report    --- maven-project-info-reports-plugin:2.7
[ERROR] Unable to determine if resource asm:asm:jar:3.1:provided exists in http://maven.glassfish.org/content/groups/glassfish
...

This not only produces a lot of errors, it also takes time. Besides I would want to limit the columns in the report to the repositories which are relevant for this project.

I wonder, is there a way to make the plugin (and all of Maven) skip specific repositories? How would you blacklist them in my project POM?

The dependency:list-repositories goal does not show this repo, but when I search through all cached POM files I see <id>glassfish-repository</id> in com.sun.jersey:jersey-server:1.8.

Answer 1

Choose one of these:

1. The correct answer is for them to remove the repository from the pom definition. See Why Putting Repositories in your POMs is a Bad Idea. There should be no reason why other open source projects are not hosted there. To convince the other repositories to publish their projects to Central, point them at the docs http://maven.apache.org/guides/mini/guide-central-repository-upload.html, or you can do the upload for them. If it's only a few artifacts that might be the easiest.

Remember, every extra repo defined in the pom impacts your build's performance, as Maven must check each repo for artifacts. It's not a big problem if you only have to add one repo... But the problem grows and next thing you know your maven build is checking 50 repos for every artifact and build time is a dog. See this email thread for more details about the impact.

2. The next best answer, if that project is abandoned, is you could patch the pom to remove the repository definition and re-upload the patched pom and the unchanged jar to Maven Central. See Guide to uploading artifacts to the Central Repository

---

Avoid these options

Every other option here is a hack and choosing any of these option will mean everyone else will need to make the same changes to fix the problem.

3. Blacklist the repository by disabling it in your settings.xml file. Unfortunately there is no unique identifier for a repository. The repository > id field can be anything the person creating the pom defines, and so the same repository url can be referenced with different ids. To find the id run with the -X option and the debug output should list the repositories id. Use something like this to disable it:

<repository>
  <releases>
    <enabled>false</enabled>
  </releases>
  <id>the repo id from X here</id>
  <name>the repo's name</name>
  <url>the repo's url</url>
</repository>

4. Force the repository to use a mirror instead. Much like 3 but to redirect the broken repository to another one.

<mirror>
  <id>Another Mirror</id>
  <url>url to mirror</url>
  <mirrorOf>id of broken repo</mirrorOf>
</mirror>

5. Force the repository to use a local Maven Repository Manager instead (even on your laptop). This was, no matters who abuses repositories in a pom, Maven will only contact your local MRM and avoid multiple, slow, network connections for each defined repo.

<mirror>
  <id>Local MRM</id>
  <url>url to MRM</url>
  <!-- Mirror EVERYTHING to your MRM -->
  <mirrorOf>*</mirrorOf>
</mirror>