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 <[email protected]> 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 < > [email protected]> 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 <[email protected]>: >> > 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: [email protected] >> For additional commands, e-mail: [email protected] >> >> >
