Robert, Stephen: 1) from my experience "release root / top-to-bottom / monolithic " is a wrong approach. please consider instead "start-from-any-module / from-bottom-up / incremental" approach, as implemented here: https://github.com/barchart/barchart-jenkins-cascade-plugin/wiki
2) it would be good to have some wiki page somewhere to flesh out all assumptions that currently go into release as well as to list the use cases people really need. here is one of my use cases: https://github.com/barchart/barchart-jenkins-tester-ecosystem/blob/master/readme.md Andrei -------- Original Message -------- Subject: Re: Multi-project releases From: Robert Scholte <rfscho...@apache.org> To: Maven Developers List <dev@maven.apache.org> Date: Sun 24 Mar 2013 09:42:27 AM CDT > Hi Stephen, > > I've just checked your code. > Most interesting is our difference of the definition "releaseRoot" (or > in my case rootProject, I think we mean the same thing with it). > If I'm correct you base it on the existence of the <scm>-section and > if it has ever been released (assuming a specific scm comment). > MRELEASE-814[1] is probably a good example for which this strategy > won't work. > I try to base it on the parent/module relationship. > > Although this looks close related to MRELEASE-516[2] it is actually a > complete other issue. > The problem I have with MRELEASE-516 is that it's not the > "plug-and-play" behavior you'd like to have, > which means that the developer is responsible for checking out > separate projects in the right structure. > > Robert > > [1] https://jira.codehaus.org/browse/MRELEASE-814 > [2] https://jira.codehaus.org/browse/MRELEASE-516 > > > Op Mon, 11 Mar 2013 12:50:38 +0100 schreef Stephen Connolly > <stephen.alan.conno...@gmail.com>: > >> Hey one and all, >> >> So we all know how multiple projects with multiple release roots are a >> pain... >> >> Here's some experiments I've been playing with... >> >> Not yet brave enough to have it fire up release:prepare >> release:perform on >> each release root, nor fire up versions:set on the downstream >> projects with >> explicit dependencies, nor lather rinse repeat until there is nothing >> needing a release... >> >> But even the simple report should be useful, and if anyone has >> suggestions >> to help improve its recommendations towards getting confidence that the >> automated stuff could work... please give me pull requests. >> >> If this proves useful, I will probably roll it into the release >> plugin... >> but for now I'll keep it in a holding pattern on github (where it is >> not in >> a default plugin groupId and hence relocation is less of an issue if >> I do >> happen to make any releases into central) >> >> $ mvn com.github.stephenc.maven:mpr-maven-plugin:list-roots >> >> from an aggregator pom should identify all the release roots and whether >> they might need a release >> >> -Stephen > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
