Also have a look at versions-maven-plugin I use properties to define outside of reactor version... then if I build a different project I do a local install of that project and then
mvn versions:update-properties -DallowSnapshots=true which updates my properties to the latest version visble to me at release time I release each project and do mvn versions:update-properties which will pick up the latest release versions -Stephen 2009/4/4 Brian E. Fox <[email protected]> > Forget about LATEST and RELEASE, these are not reproducible down the road. > > The way I like to manage my dependencies is that they stay using the > release version until a change to it that I need occurs. Then that > dependency is changed to use the new snapshot. Hopefully you are using > properties or dependencyManagement to reduce the number of places this needs > to be changed to 1 per product group of modules. Then when it's time to > release you know all the other things you must release because they are set > as snapshots. > > -----Original Message----- > From: Zac Thompson [mailto:[email protected]] > Sent: Friday, April 03, 2009 8:43 PM > To: Maven Users List > Subject: Re: Maven 2.0 project versions, dependency versions, and perpetual > releasing > > I am willing to continue using snapshots during the dev cycle. I > don't seek to eliminate them completely, but they are getting in my > way. It's not SNAPSHOT versions of the projects themselves that is > the obstacle, but SNAPSHOT dependencies. > > My challenge is that the dev cycle for a slice of the system could be > extremely short (say, two hours), at which time I might need to update > the versions and the dependencies for a few poms as I build them in > sequence, and then update the dependency versions in many other POMs > (perhaps 20, even though they may not be modified yet) in order to > facilitate future development. > > As an example, let's say a developer changes a component, but also > updates a shared utility library as part of the work. There's no > problem with the checked-in component and library poms being > SNAPSHOTs, but I have only four options for the dependency version: > > 1) component depends on SNAPSHOT dependency. Easy for the developer > to work with and test, impossible for me to manage. This is where we > are now. > > 2) component depends on specific release version of library: Feels the > most authentic and "proper", but then Dev has to wait for a release > build of the library and an update to the component POM for the new > dependency version in order to use it for the component work. Also, I > have to update all the other POMs that depend on the library. > > 3) component depends on virtual "RELEASE" version of library (or > version range if supported and more appropriate). This is a lot like > #1, but I won't have to update the component POMs when I build a new > library. But it worsens build reproducibility, and the Dev still has > to wait for an "official" library build in order to try out their > changes to the component. This is a troublesome bottleneck for both > #2 and #3 -- our split is just not that perfect that we can modify > each piece in isolation. They need a way to use the new library they > just built on their desktop while developing the component. They > could update the component pom to depend on the snapshot of the > library (temporarily back to #1), but then we risk them checking in > that snapshot dependency, which will mess up any other devs on the > same component. I'd like them to be able to avoid updating POMs > unless there's a meaningful change to our dependency tree. > > 4) component depends on "LATEST" library. This allows the developer > to work with the latest release until they start development, and then > they'll find their self-built SNAPSHOTs. I also don't have to update > lots of poms with every library build. This is close to #1, but at > least I can be fairly sure that there will be no SNAPSHOT versions > found by my scheduled builds. I can dimly see risks surrounding > timing issues if they build a SNAPSHOT from an old checkout after my > release build, but I can't fix everything. > > Any thoughts? #4 looks the best to me at the moment, but I haven't > tried it yet. Still trying to wrap my head around it. > > Zac > > On Fri, Apr 3, 2009 at 3:49 PM, Brian E. Fox <[email protected]> > wrote: > > Use snapshots during your dev cycle and publish your > > non-developer-desktop builds as official releases. There is the > > dependency-maven-plugin that can ease the updates of cross dependencies, > > but if you structure your build tree effectively, this will be minimal. > > You're on the right track, but don't throw out the notion of snapshots > > just to avoid ever changing the poms. > > > > -----Original Message----- > > From: Zac Thompson [mailto:[email protected]] > > Sent: Friday, April 03, 2009 4:16 PM > > To: [email protected] > > Subject: Maven 2.0 project versions, dependency versions, and perpetual > > releasing > > > > I also posted this question on stackoverflow, but I wanted to go "to > > the source", as it were. > > > > How should we manage the project and dependency versions in our POM > > hierarchy? I apologize for the length of the message. The first > > paragraph is probably all that's needed, but I'm not good at > > self-editing and I wanted to give as much context as possible. > > > > Scenario: The system has number of components, each with its own POM. > > There are some long dependency chains (A depends on B depends on C, > > etc.). I want each "non-developer-desktop" build to be a potential > > release candidate -- if it passes QA, we will deploy it without > > rebuilding. In other words, I never want to build SNAPSHOT versions as > > part of my regularly scheduled builds, only versions like 1.3.0.5, > > 1.3.0.6, etc. I also want to enable the developers to work on multiple > > components at once. > > > > To forestall some expected suggestions: the Maven Release Plugin > > doesn't help me ... unless there's some magic way I can have my > > dependency versions not be SNAPSHOTs in the POMs but still let the > > developers work on more than one component at once? > > > > How should we manage the project and dependency versions in all of our > > POMs? Right now it's just SNAPSHOTs everywhere, which makes things > > simple for the developers (they started with SNAPSHOTs and never > > concerned themselves with anything else). But it's worrying at > > deployment time (builds with SNAPSHOT dependencies are not > > well-defined, and not reproducible). > > > > I'd like to avoid excessive version juggling at build time, but right > > now I don't see any way around it. > > > > Let's say I have components util, libj, libk, APP, and UI, with > > dependencies as follows: > > libj -> util (libj depends on util) > > libk -> util > > APP -> libj > > UI -> libj, libk > > > > I have development teams working on APP and UI, and they will > > sometimes need to make changes/additions to some of the dependencies > > (even util) in order to enable their current work. How should the > > checked-in POM and dependency versions for each component look? > > > > I'm prepared to hear that I may be taking the wrong approach to this > > problem. All suggestions welcome. > > > > --------------------------------------------------------------------- > > 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] > > > > > > --------------------------------------------------------------------- > 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] > >
