That assumes that you have access to an up-to-date POM. What if you depend on 0.6-SNAPSHOT and in that POM it shows URL = XYZ, however mean while that project has moved on, and around, and is using a different URL from a different POM in a newer variant of the same snapshot or some later variant. There's a lot of assumption, as opposed to convention, going on here. Granted there's a fair bet that it won't have moved, however with the current release plugin and SCM provider for git, unless you rely on the CLI real Git, you can not use ~/.ssh/config to keep the SCM URL consistent across physical server changes.
Do you take a stab at releasing these artifacts regardless and fail if you don't have permissions (SCM and MVN repo)? What about a mix of repos, some SVN, some Git? Just try anyway? Two different SVNs with two different sets of credentials? EDIT: I see this has been addressed in Stephens last email. Sending unchanged anyway. I presume that this mode would be explicitly activated? And that we're not talking about a new default. Fred. On Sun, Mar 24, 2013 at 9:35 PM, Andrei Pozolotin < andrei.pozolo...@gmail.com> wrote: > re: "where these required-to-be-released-artifacts live? " > by looking into <scm> tag, and using still one more convention (to be > decided) > where to look locally before attempting independent remote clone. > > -------- Original Message -------- > Subject: Re: Multi-project releases > From: Fred Cooke <fred.co...@gmail.com> <fred.co...@gmail.com> > To: Maven Developers List <dev@maven.apache.org> <dev@maven.apache.org> > Date: Sun 24 Mar 2013 03:27:10 PM CDT > > * can your envisioned plugin automatically recursively release all other > dependencies moving upward in the reactor dependency tree? > > > Generalising this out a bit, if it's not a multi-module build we're talking > about, and it's not in SVN (repo per project/module in Git for example), > how will the proposed plugin even find where these > required-to-be-released-artifacts live? > > > On Sun, Mar 24, 2013 at 9:23 PM, Andrei Pozolotin > <andrei.pozolo...@gmail.com> wrote: > > > you are right, I am not: "You are not getting my plan" :-) > * please define what you mean by "release root"? > * can release root contain other release roots as modules? > * can I release the release root w/o releasing the release root modules? > (need a better term :-)) > * can your envisioned plugin automatically recursively release all other > dependencies moving upward in the reactor dependency tree? > > -------- Original Message -------- > Subject: Re: Multi-project releases > From: Stephen Connolly <stephen.alan.conno...@gmail.com> > <stephen.alan.conno...@gmail.com> > To: Andrei Pozolotin <andrei.pozolo...@gmail.com> <andrei.pozolo...@gmail.com> > Cc: Maven Developers List <dev@maven.apache.org> <dev@maven.apache.org>, > Robert Scholte<rfscho...@apache.org> <rfscho...@apache.org> > Date: Sun 24 Mar 2013 02:32:39 PM CDT > > On Sunday, 24 March 2013, Andrei Pozolotin wrote: > > 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 > > > You are not getting my plan. > > The plugin I envision will allow picking a release root from the > reactor's set of release roots (suggesting which ones need a release) > and then run release on that one. > > You then iterate until it says all done or you have released what you > > need > > No Big Bang from my PoV > > > > > 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> <rfscho...@apache.org> > <javascript:_e({}, > 'cvml', 'rfscho...@apache.org');> > To: Maven Developers List <dev@maven.apache.org> <dev@maven.apache.org> > <javascript:_e({}, 'cvml', '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> <stephen.alan.conno...@gmail.com> > <javascript:_e({}, 'cvml', > '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 > <javascript:_e({}, 'cvml', 'dev-unsubscr...@maven.apache.org');> > For additional commands, e-mail: dev-h...@maven.apache.org > <javascript:_e({}, 'cvml', 'dev-h...@maven.apache.org');> > > > > -- > Sent from my phone > > >
