You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Ben Podgursky <bp...@gmail.com> on 2014/06/11 02:27:22 UTC
Concurrent maven processes using the same repository failing when new
snapshot version downloaded
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
Re: Concurrent maven processes using the same repository failing when
new snapshot version downloaded
Posted by Ben Podgursky <bp...@gmail.com>.
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 <bp...@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 <bp...@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
>>
>>
>
Re: Concurrent maven processes using the same repository failing when
new snapshot version downloaded
Posted by Ben Podgursky <bp...@gmail.com>.
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 <bp...@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
>
>
Re: Concurrent maven processes using the same repository failing when
new snapshot version downloaded
Posted by Kristian Rosenvold <kr...@gmail.com>.
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 <bp...@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