>
> ><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>
>
> >
> >
> > 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
> >
>
