I haven't seen that exact problem but I feel your pain. I too spent the better part of today trying to figure out why my build was failing. We have been having nothing but trouble with Nexus and Maven3 with the time-stamped snapshots and all the various metadata files that Nexus spits out (which confuse Maven and IDEs). We thought we had those resolved so now Nexus refuses to update the regular pom file (the non-timestamped) one and of course that broke the build. I long for the Maven2 days of no timestamped snapshots. Only way to reliably build with Nexus/Maven3 is to delete the local repo it seems...or replace Nexus with Artifactory perhaps.
On Fri, Aug 24, 2012 at 2:31 PM, Laird Nelson <ljnel...@gmail.com> wrote: > I fear this is a stupid question, but I can't find any information anywhere > about Maven metadata. :-( > > I have the world's simplest Jenkins/Maven/Nexus setup. > > I have a job on Jenkins that (today only, never before) began failing > because it claims it cannot resolve various SNAPSHOT artifacts from Nexus. > It is effectively invoking mvn -U clean install on an ear project, which > (of course, as you'd expect) has various runtime dependencies. > > The various errors look like this: > > Caused by: org.apache.maven.model.resolution.UnresolvableModelException: > Could not find artifact com.foobar.pomtype-api:pom:1.009-SNAPSHOT > > > But the pomtype-api/1.009-SNAPSHOT directory is of course present, in > the very repository that Maven itself simultaneously documents as the > place it's looking and the place that theoretically does not contain > the artifact. It is chock full of timestamped snapshots, each of > which has a .pom extension, and each of which was uploaded > successfully by a previous Jenkins job. > > > I have run across this issue various times over the years and have > always chalked it up to black magic. Some combination of poking and > prodding and redoing and waiting and -U etc. always seems to clear the > mud out of the mechanism. Not this time, and I'm tired of not > understanding how this all works. > > > Guessing in the dark, I'm assuming that Maven is somehow not able to > figure out how to turn "1.009-SNAPSHOT" into, e.g., > "1.009-20120621.124828-107" and thus concludes that there is no > 1.009-SNAPSHOT artifact at all. Equally in the dark, I'm presuming > this has something to do with the (undocumented?) maven-metadata.xml > file, which doesn't seem to contain any useful information: > > > <metadata modelVersion="1.1.0"> > <groupId>com.foobar</groupId> > <artifactId>pomtype-api</artifactId> > <version>1.009-SNAPSHOT</version> > <versioning> > <snapshot> > <timestamp>20120809.231215</timestamp> > <buildNumber>116</buildNumber> > </snapshot> > <lastUpdated>20120809231215</lastUpdated> > <snapshotVersions> > <snapshotVersion> > <extension>pom</extension> > <value>1.009-20120809.231215-116</value> > <updated>20120809231215</updated> > </snapshotVersion> > <snapshotVersion> > <classifier>tests</classifier> > <extension>jar</extension> > <value>1.009-20120809.231215-116</value> > <updated>20120809231215</updated> > </snapshotVersion> > </snapshotVersions> > </versioning> > </metadata> > > > I don't see how Maven could conclude much from this, but this seems to > be what it consults as part of its resolving snapshots; I can see this > being downloaded in the logs. > > > When Maven heads off to resolve 1.009-SNAPSHOT to a timestamped > version, how does it do it? Why doesn't--in this case--it pick the > "most recent" snapshot, and what would cause it to do so? > > > Let's pretend just for kicks that redeploying a new snapshot is not a > possibility (the answer SURELY can't be to redeploy a new snapshot to > somehow cause the magic to happen). What steps should I take? Where > do I start looking to resolve this issue? > > > Thanks, > > Laird > > > -- > http://about.me/lairdnelson --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
