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> To: Maven Developers List <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> >> To: Andrei Pozolotin <andrei.pozolo...@gmail.com> >> Cc: Maven Developers List <dev@maven.apache.org>, Robert Scholte >> <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> <javascript:_e({}, >>> 'cvml', 'rfscho...@apache.org');> >>> To: Maven Developers List <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> <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 >>
