do you guys use mvn release:prepare and mvn release:perform? This should increment the versions automatically!
Please also read through the section covering <dependencyManagement> in the 'definitive maven guide'. LieGrue, strub --- On Thu, 9/10/09, Andrew Close <[email protected]> wrote: > From: Andrew Close <[email protected]> > Subject: Re: Maven and ClearCase UCM > To: "Maven Users List" <[email protected]> > Date: Thursday, September 10, 2009, 4:29 PM > On Thu, Sep 10, 2009 at 8:59 AM, > Bruce Albrecht<[email protected]> > wrote: > > Is anyone using Maven with ClearCase UCM with > developers using children > > streams with dynamic views? If so, how do you manage > bumping the POM > > versions? Do you rely on the developers doing it > manually, or use an > > automatic process? If we automate it, it looks like > we potentially need to > > strip the -SNAPSHOT in the POMs' version before > creating a baseline, create > > a baseline, update the POMs to new -SNAPSHOT versions, > and then create a > > second baseline so that the developers can rebase > against it. Is there a > > better way that we're overlooking? Thanks! > > hi Bruce, > > we recently converted our SCM from MS VSS to CC UCM and our > build > system from a very poor ANT implementation (not that ANT is > poor, our > implementation was) to Maven. we're still struggling > with growing > pains/conversion pains and have yet to automate > versioning. i'm > hoping that others speak up cause we'd like some ideas as > well. :) > our setup/process is pretty poor at the moment mainly due > to the > amount of baggage our systems carry. > we currently rely on the developers to set their versions > to SNAPSHOT > during development. everything on the dev stream is > SNAPSHOT. when > we move to Integration testing we create a new stream that > everyone > delivers to and the versions are set to hard > versions. everything is > built and tested and if ok delivered to the Prod stream by > SCM. > i can give you more details, but i'm hoping others step up > with better > solutions cause i'll be the first to tell you ours isn't > the way to > go. :) > > -- > Andrew Close > > --------------------------------------------------------------------- > 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]
