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]
