2009/3/26 Martin Eigenbrodt <[email protected]> > 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.
eh... how is invoking a maven plugin not a "native" maven solution > > > 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. mvn versions:update-parent presto-chango you now have the latest deployed 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 >
