How do I stop Maven 2.x from trying to retrieve non-existent pom.xml files for dependencies every build?

Question

In my project, there are a number of dependencies that are transitively included from other dependencies that do not have pom.xml files available in any of our corporate repositories. These are internal jar-only libraries supported by various teams which have been uploaded into repositories for convenience from non-Maven teams, however these repositories are unfortunately not mine to play with.

For these dependencies, Maven insists on trying to retrieve the poms from each of my repository list every time I run a build, or mvn dependency:list. This means maven tries to retrieve 8x pom files from 7 different repository locations, and given this is over the global corporate WAN; it's really slow.

e.g. for one particular dependency

C:\Working\dev\workspace\project>mvn dependency:list
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'dependency'.
[INFO] ------------------------------------------------------------------------
[INFO] Building project
[INFO]    task-segment: [dependency:list]
[INFO] ------------------------------------------------------------------------
[WARNING] Unable to get resource 'aGroupId:anArtifactId:pom:4.0.14i' from repository inhouse (http://someRepo1/proximity/repository/inhouse): While configuring wagon for 'inhouse': Unable to apply wagon configuration.
Downloading: http://someRepo1/proximity/repository/extFree/aGroupId/anArtifactId/4.0.14i/anArtifactId-4.0.14i.pom
[INFO] Unable to find resource 'aGroupId:anArtifactId:pom:4.0.14i' in repository extFree (http://someRepo1/proximity/repository/extFree)
Downloading: http://someRepo1/proximity/repository/externalNonFree/aGroupId/anArtifactId/4.0.14i/anArtifactId-4.0.14i.pom
[INFO] Unable to find resource 'aGroupId:anArtifactId:pom:4.0.14i' in repository extNonFree (http://someRepo1/proximity/repository/externalNonFree)
Downloading: http://someRepo2/efs/dist/maven/maven2-repository/incr/common/lib/aGroupId/anArtifactId/4.0.14i/anArtifactId-4.0.14i.pom
[INFO] Unable to find resource 'aGroupId:anArtifactId:pom:4.0.14i' in repository efsRepo (http://someRepo2/efs/dist/maven/maven2-repository/incr/common/lib)
Downloading: http://someRepo2/efs/dist/btijava/maven2-repository/incr/common/lib/aGroupId/anArtifactId/4.0.14i/anArtifactId-4.0.14i.pom
[INFO] Unable to find resource 'aGroupId:anArtifactId:pom:4.0.14i' in repository efsBTI (http://someRepo2/efs/dist/btijava/maven2-repository/incr/common/lib)
Downloading: http://someRepo3/maven/aGroupId/anArtifactId/4.0.14i/anArtifactId-4.0.14i.pom
[INFO] Unable to find resource 'aGroupId:anArtifactId:pom:4.0.14i' in repository internal.repo (http://someRepo3/maven)
Downloading: http://repo1.maven.org/maven2/aGroupId/anArtifactId/4.0.14i/anArtifactId-4.0.14i.pom
[INFO] Unable to find resource 'aGroupId:anArtifactId:pom:4.0.14i' in repository central (http://repo1.maven.org/maven2)`
...
etc
...
[INFO] [dependency:list {execution: default-cli}]
[INFO]
[INFO] The following files have been resolved:
... etc
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 20 seconds
[INFO] Finished at: Tue Jan 26 15:01:48 CST 2010
[INFO] Final Memory: 31M/74M
[INFO] ------------------------------------------------------------------------

On the other hand, for POMs which are just invalid (older modelVersion, or corrupt/invalid XML, for example) it just checks my local repo, complains it's invalid and then continues. Which is fine; at least that doesn't try again over the WAN.

Is there a way (setting, override, repository config change) I can prevent Maven's dependency plugin/artifact resolver from repeatedly trying to locate missing POMs, if it already has the jar file in the local repo?

Specs: Maven 2.2.1 (default superPOM plugin definitions) JDK 1.6.0_18

Tizzy

Answer 1

Pascal's answer is correct for two local build workarounds. However, your best option is to request the owners of these projects to create POMs for the artifacts. They don't need to be complex, the simple alternative that Maven is using internally will work:

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>aGroupId</groupId>
  <artifactId>aArtifactId</artifactId>
  <version>4.0.14i</version>
</project>

Snowflake

I was hoping to avoid having to trudge around the corporation finding owners of all of the artifacts. But if there really is no way to alter this part of Maven's behaviour, I guess I'll have to do that. It just seems strange to me that Maven will accept a corrupted/incompatible local repo POM without attempting to retrieve it again, but a non-existent one it will keep trying forever, even if it succeeded in retrieving a jar. – Tizzy

I used this work around and it worked great for me. I had tried setting timeouts on the various repositories without success. – Belia

Wow, it's Brett Porter from Maven team! – Desireah

creating new pom file in the local repo and putting this was worked. thanks. – Sister

Answer 2

Downloading a POM is really a central concept in Maven to support transitive dependencies (actually, a dependency isn't just a JAR, see 3.5.5. Maven's Dependency Management for nice details on that) so I don't know if you can prevent it.

Of course, the right thing to do would be to fix the root cause of the problem. But if you can't, maybe you can run your build in offline mode (using the -o option). Or maybe you could just "install" the artifacts in your local repository using install:install-file and instruct the plugin to generate a pom for them using the generatePom optional parameter (but this obviously doesn't "scale" really well).

Hankow

Thanks Pascal. Yeah, I understand that it's a central concept, but unfortunately, as is often the case in (intentionally) siloed corporates I have no control over their Maven repository, but then again I need to be able to retrieve their build artifacts. For some dependencies it's not even clear who is responsible for them, so difficult to know who to ask! If other experts have come to the same conclusion that there is no way to do this, that's fine - at least I know that I'm not crazy. And yeah, the local hacks aren't really optimal for the scalability reasons you alude to. – Tizzy

Answer 3

Set up a Nexus Repository (or similar) and upload the artifacts there. Nexus will automatically create basic poms for artifacts you upload.

Jurisprudent

This is the solution I just used when dealing with sonatype-flex-group not having poms on their halo project. Create a simple pom which I then deployed to the "3rd party releases" repo in Nexus. The builds then continue quite happily, and in the "public" aggregate repo you'd never know that the pom and swc are from different internal/proxy repos. – Roanne

Answer 4

• download to local repo
• setup nexus and upload
• work offline

maybe the best idea is to get rid of maven all the way, it is horror !

Verbose