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]
