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 21:45:00 GMT
After a bit of hunting, it turns out Jenkins has an option under "Manage
Jenkins" -> "Configure System" -> "Maven Project Configuration" -> "Local
Maven Repository" -> "Local to the executor" which will use an isolated
repository for each executor process, which solves this pretty cleanly.
 Thanks for the tip.


On Wed, Jun 11, 2014 at 1:24 AM, Ben Podgursky <bpodgursky@gmail.com> wrote:

> 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