Trevor Harmon wrote: > Consider this scenario: > > Alice and Bob are working independently on two different applications, > AppA and AppB. Both applications depend on an in-house shared library, > Foo, that Alice and Bob are working on together. They have both > checked out Foo's trunk and are regularly committing changes to it. > > Because Foo is undergoing heavy development, AppA and AppB depend on > Foo 2.1-SNAPSHOT, but now Foo is looking pretty stable, and Alice's > AppA needs some of the features scheduled for Foo 2.2, so she decides > to perform a release of Foo 2.1 and does the usual release procedure: > > 1) Changes Foo's version from 2.1-SNAPSHOT to 2.1 and checks it into > the trunk > 2) Deploys Foo 2.1 to the company's internal repository > 3) Tags the Foo trunk as the 2.1 release branch > 4) Changes Foo's version from 2.1 to 2.2-SNAPSHOT and checks it into > the trunk > 5) Changes AppA's dependency to point to Foo 2.2-SNAPSHOT > > But what about Bob? He's still working with Foo 2.1-SNAPSHOT for his > AppB. If he updates his working copy of Foo's source code, any changes > he makes to Foo will be built as a 2.2-SNAPSHOT release, since Foo's > trunk is now 2.2-SNAPSHOT. This is a major problem because his AppB > has a dependency on 2.1-SNAPSHOT, so the next time he tests AppB, it > will pick up the old Foo 2.1-SNAPSHOT, ignoring any changes Bob makes > in Foo. He will probably waste a lot of time debugging, at least until > he happens to notice that Foo's version has changed. > > What can be done to prevent Bob's problem?
Use an inhouse global POM that is used as parent everywhere and define the versions used there in a depMgmt section. - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
