strange dependency resolution errors in mvn 3.0

[Craig <su...@gmail.com>]

Hi,

Since upgrading to maven 3.0 our (previously reliable) Bamboo build
server has been having a lot of randomly failing builds. I think I
have narrowed the problem down to these kinds of messages from maven:

 [WARNING] The POM for my-group:my-artifact:jar:1.0-SNAPSHOT is
missing, no dependency information available

Looking in the local repo of the build server, the pom is indeed
missing, although the jar/source/javadoc artifacts are there. The
project with the missing pom is also being built by mvn3 on the build
server, and has succeeded in the past. An example of the command line
being invoked by Bamboo is:

 /disk/apache-maven-3.0/bin/mvn clean deploy site -e -B -U -DperformRelease=true

So something seems to be deleting poms from the local repository. I
can't think of any other tool which would access this directory other
than maven 3 invoked as above, so it must be maven or a plugin
deleting this file.

A second problem, brought about by the first, is that after not
finding the pom, mvn3 carries on with the build, even though it hasn't
added any of the transitive dependencies from the missing pom to the
classpath. This causes spurious build errors, like compilation errors,
or even sometimes test failures, which are very misleading, if you
didn't notice the aforementioned warning.

Another point to note is that the missing pom is available in our
nexus repo, but after not finding the pom in the local repo, mvn3
doesn't seem to try the nexus repo. If the entire directory is deleted
from the local repo, then mvn will resolve again from nexus. These
points suggest a possible metadata problem?

Finally, to reiterate, these errors appear to be somewhat random, with
builds working fine for a few days, then starting to fail.

Any ideas,

thanks.
Craig

using: maven 3.0, nexus 1.8, bamboo, linux, jdk6

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: strange dependency resolution errors in mvn 3.0

[Jon Paynter <ki...@gmail.com>]

On Thu, Nov 4, 2010 at 3:22 PM, Craig <su...@gmail.com> wrote:

> Hi,
>
> Since upgrading to maven 3.0 our (previously reliable) Bamboo build
> server has been having a lot of randomly failing builds. I think I
> have narrowed the problem down to these kinds of messages from maven:
>
>  [WARNING] The POM for my-group:my-artifact:jar:1.0-SNAPSHOT is
> missing, no dependency information available
>
> Looking in the local repo of the build server, the pom is indeed
> missing, although the jar/source/javadoc artifacts are there. The
> project with the missing pom is also being built by mvn3 on the build
> server, and has succeeded in the past. An example of the command line
> being invoked by Bamboo is:
>
>  /disk/apache-maven-3.0/bin/mvn clean deploy site -e -B -U
> -DperformRelease=true
>
> So something seems to be deleting poms from the local repository. I
> can't think of any other tool which would access this directory other
> than maven 3 invoked as above, so it must be maven or a plugin
> deleting this file.
>
> A second problem, brought about by the first, is that after not
> finding the pom, mvn3 carries on with the build, even though it hasn't
> added any of the transitive dependencies from the missing pom to the
> classpath. This causes spurious build errors, like compilation errors,
> or even sometimes test failures, which are very misleading, if you
> didn't notice the aforementioned warning.
>
> Another point to note is that the missing pom is available in our
> nexus repo, but after not finding the pom in the local repo, mvn3
> doesn't seem to try the nexus repo. If the entire directory is deleted
> from the local repo, then mvn will resolve again from nexus. These
> points suggest a possible metadata problem?
>
> Finally, to reiterate, these errors appear to be somewhat random, with
>  builds working fine for a few days, then starting to fail.
>

This sounds familliar....  You mention after deleting the entire directory
mvn will resolve from nexus.   One of the new features of maven (a bug in my
personal opinion) is that it will try once to resolve an artifact, from the
remote repository, and if it fails, it writes a status file in your local
repository telling futue attempts to wait until some amount of time has
elapsed.

So check your previous build logs and nexus logs for failures to the
offending resources and see if that leads anywhere.