views:

1088

answers:

3

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

+3  A: 

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 mvn install:install-file in order to generate a POM for them (but this obviously doesn't "scale" really well).

Pascal Thivent
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.
Chad
+3  A: 

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>
Brett Porter
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.
Chad
A: 

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

Michael Bushe