2009/3/26 Martin Eigenbrodt <[email protected]> > > > > ><SNIP> > > > 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 > > > > The Plugin is "native". "A little script invoking the version plugin" is > not > native since you need that script and make sure it is invoked before every > build. (Or at least nightly ..) > > //Martin Eigenbrodt > > > > > > > > > > > > > > > 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 know this, but again it is a manual solution. If you want AppB (I'm using > the originall posters example) to stay up to date you have > to make sure versions:update-parent is called before every build and you > have your pom changed each time and so need a scm checkin. > This is a complicated workaround for the missing feature: > <parent> > <artifactId>foo</artifactId> > <version>LATEST</version> > </parent>
And that prevents your build from being reproducible... note that AFAIK is nothing stopping you from using a range.... <parent> <version>[1.0,2.0-!)</version> </parent> (Of course you'd face the same issues as LATEST) > > > > > > > > > > > > > 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 > > > > > >
