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] > >
