maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Podgursky <bpodgur...@gmail.com>
Subject Re: Concurrent maven processes using the same repository failing when new snapshot version downloaded
Date Wed, 11 Jun 2014 08:24:49 GMT
Thanks Kristian, I'll check that out.  Are there any tickets I could follow
to keep an eye out for the fix?


On Tue, Jun 10, 2014 at 10:55 PM, Kristian Rosenvold <
kristian.rosenvold@gmail.com> wrote:

> This is a known problem (old one), which might actaully be getting a
> fix "soon". In the meantime, checkout
>
>
> http://blog.sonatype.com/2009/01/maven-continuous-integration-best-practices/
>
> Kristian
>
>
> 2014-06-11 2:27 GMT+02:00 Ben Podgursky <bpodgursky@gmail.com>:
> > Hi all,
> >
> > I'm running into a problem where maven processes using a shared
> repository
> > are getting exceptions when a new snapshot dependency is deployed.  Our
> > setup is:
> >
> > - We use Jenkins continuous integration builds.  The builds are just
> > running a simple "mvn clean deploy".
> > - Our build machines often run builds for two projects simultaneously.
> >  When running simultaneously, the builds will share a maven respository.
> >
> > We have (for simplification) three projects A, B, and C.  Each of these
> is
> > deployed as a snapshot at the end of a successful build.  Projects B and
> C
> > each depend on a snapshot version of of project A.
> >
> > Intermittently, when projects B and C are running simultaneously on a
> > machine, the build which started first will begin to fail all tests with
> > java.lang.NoClassDefFoundError, where the classes not found belong to
> > project A.  I've verified that the classfiles are present in A's deployed
> > jar.
> >
> > I *believe* what is happening is:
> >
> > 1) project B begins building, and starts surefire tests.
> > 2) project A deploys a new snapshot version (possibly from a different
> > machine)
> > 3) project C begings building.  Because our snapshot update policy is set
> > to "always", it downloads the new version of "A-1.0-SNAPSHOT.jar", and
> > replaces the previous version in the local respository
> > 4) the tests for project B start to fail because they are using a
> reference
> > to a file which has been deleted
> >
> > I've looked into what surefire is putting on the classpath, and even
> though
> > the repository has the specific version of the snapshot available, (ex
> > "A-1.0-20140610.213850-369.jar"), it's putting
> > "analysis_lib-1.0-SNAPSHOT.jar" on the classpath.  I don't understand why
> > maven would prefer to use the artifact which could get replaced rather
> than
> > the semi-permanent artifact (I understand snapshot versions aren't
> > permanent, but it would at least survive for the duration of the build.)
> >
> > My questions are:
> >
> > - does this sequence of events seem plausible, or is there another
> > explanation to the exceptions I'm seeing?
> >
> > - is there a way I can force maven to put the timestamped version of
> > artifacts on the classpath instead of the SNAPSHOT versions?  I
> understand
> > I can specify the timestamp in the pom.xml, but that's not what I want--I
> > just want it to choose the current version when the build starts, and use
> > that for the duration of the build.  I'm also familiar with mvn
> > versions:lock-snapshots, but I'd rather avoid it if possible because (1)
> it
> > adds build complexity and (2) it doesn't lock versions pulled in
> > transitively (ex D -> A -> B, if D was a snapshot), since I don't want to
> > deploy artifacts with locked versions
> >
> >
> > Thanks for your time,
> >
> > Ben
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message