Hello Trevor, contrary to some responses here I don't think your issues is SCM/Version Control issue. This is not your fault. Your issue is missing "soft" or dynamic version support in maven. Actually the responses propose some workarounds:
1.Manual: > An easy solution is: When Alice prepares the release, she says "Hey > Bob, I'm doing a release of Foo". This is obviously not a solution if ther is not just foo but foo1, foo2 to fo10 and AppA to AppZ. 2. Custom scripts >We use a little script >that invokes the version plugin and checks in the pom.xml if versions were >updated. Hudson runs the update script nightly. This looks like a working solution. However a "native" Maven Solution would be better. 3. innhouse parent pom workaround >Use an inhouse global POM that is used as parent everywhere and define the >versions used there in a depMgmt section. How can you make sure you always use the latest version of the parent POM? This changes the problem from updating the reference to foo into updating the reference to the parent. I'm new to maven and have used ant & ivy before. With ivy you're able to design AppA an AppB so they will always pick up the latest version of foo. However a released artifact can still contain information about the exact version used to build the artifact. I'm really missing this feature in maven. An if I look at your post and the proposed workarounds I think others are missing it a well, maybe they just don't know... I've already posted about this isse before, but there has not been any response yet: http://www.nabble.com/Soft-dependency-versions-combined-with-repeatable-builds-td22697640.html Best regards, Martin 2009/3/26 Martin Gainty <[email protected]> > > The only way to accomplish this is called version control > but since you do not want to use version control .. > > how do you achieve intelligent merging *on the same component codebase* > without version control > ? > Martin > ______________________________________________ > Verzicht und Vertraulichkeitanmerkung / Disclaimer and confidentiality note > Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene > Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte > Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht > dient lediglich dem Austausch von Informationen und entfaltet keine > rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von > E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. > This message is confidential and may be privileged. If you are not the > intended recipient, we kindly ask you to please inform the sender. Any > unauthorised dissemination or copying hereof is prohibited. This message > serves for information purposes only and shall not have any legally binding > effect. Given that e-mails can easily be subject to manipulation, we can not > accept any liability for the content provided. > > > > > > > > Subject: RE: Possible problem when multiple developers depend on SNAPSHOT > versions > > Date: Wed, 25 Mar 2009 22:18:53 -0400 > > From: [email protected] > > To: [email protected] > > > > +10 > > > > ________________________________ > > > > From: B Smith-Mannschott [mailto:[email protected]] > > Sent: Wed 3/25/2009 5:49 PM > > To: Maven Users List > > Subject: Re: Possible problem when multiple developers depend on SNAPSHOT > versions > > > > > > > > With all due respect to others' responses, the scenario described > > below is not due to misuse or lack of version control. Indeed, the > > scenario below clearly describes version control *working as > > designed*. > > > > Bob finds himself unwittingly building snapshots of 2.2, while his > > project continues to depend on snapshots of 2.1, so he doesn't see his > > own changes. The problem, however, is neither source control nor > > maven: it's lack of communication. > > > > Something like cutting a release needs to be coordinated among the > > developers working on a component. Alice and Bob need to talk to each > > other about library Foo, particularly with respect to cutting a > > release. There's no way around this. > > > > // ben > > > > On Wed, Mar 25, 2009 at 20:10, Trevor Harmon <[email protected]> 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? > > > > > > Trevor > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > > > _________________________________________________________________ > Windows Live™ SkyDrive: Get 25 GB of free online storage. > http://windowslive.com/online/skydrive?ocid=TXT_TAGLM_WL_skydrive_032009
