Return-Path: X-Original-To: apmail-maven-dev-archive@www.apache.org Delivered-To: apmail-maven-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id EDC81F7A6 for ; Wed, 27 Mar 2013 20:59:46 +0000 (UTC) Received: (qmail 90146 invoked by uid 500); 27 Mar 2013 20:59:46 -0000 Delivered-To: apmail-maven-dev-archive@maven.apache.org Received: (qmail 89870 invoked by uid 500); 27 Mar 2013 20:59:46 -0000 Mailing-List: contact dev-help@maven.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Maven Developers List" Reply-To: "Maven Developers List" Delivered-To: mailing list dev@maven.apache.org Received: (qmail 89860 invoked by uid 99); 27 Mar 2013 20:59:46 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 27 Mar 2013 20:59:46 +0000 Received: from localhost (HELO columbia) (127.0.0.1) (smtp-auth username rfscholte, mechanism login) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Wed, 27 Mar 2013 20:59:46 +0000 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Maven Developers List" Subject: Re: Multi-project releases References: <514F2782.8040103@gmail.com> <514F60A7.2020307@gmail.com> <514F9138.2010307@gmail.com> Date: Wed, 27 Mar 2013 21:59:42 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Robert Scholte" Message-ID: In-Reply-To: <514F9138.2010307@gmail.com> User-Agent: Opera Mail/12.14 (Win32) @Andrei, I've taken a look at your project and I think I understand what you're trying to do with the maven-cascade-release-plugin. It requires a non-chained project structure, that's not an option for us. If these local-aggregators can be under source control and if they can be layered we have a different challenge. Stephen, I can give my thoughts a try by forking your plugin, but it's missing tests. Robert Op Mon, 25 Mar 2013 00:50:16 +0100 schreef Andrei Pozolotin : > got it, thank you. > > this is the problem I have solved with my jenkins plugin. > > there your "release root" goes by the name of "layout project". > > I also go 2 steps further: > 1) I require that there are no declarations in non-root > projects, so all modules and parents are independent. > 2) I do recursive release of the whole layout automatically, from any > point in the middle tree, releasing what needs be released. > > -------- Original Message -------- > Subject: Re: Multi-project releases > From: Stephen Connolly > To: Andrei Pozolotin > Cc: Maven Developers List , Robert Scholte > > Date: Sun 24 Mar 2013 03:59:40 PM CDT >> There is a trick called the "local aggregator pom" that advanced users >> employ. >> >> You create a local only pom and list as modules all the projects you >> are working on. >> >> Each of those checked out projects are "release roots" if they are the >> root of a multi-module release. >> >> The local only pom allows within reactor resolution of dependencies so >> as soon as you make changes to a module, the rest if the modules in >> the reactor can pick them up (by linking in -snapshot dependencies) >> >> Now when it comes time to release from such a local aggregator, you >> need to find out which ones you've made changes on and release each >> one in turn, perhaps upping within reactor dependencies as you go. >> >> Some of the locale modules could be in git, some in svn, some in HG, >> etc. but each release root has all its child modules in the one SCM >> root and part of the same tag >> >> That is the problem space I am addressing >> >> On Sunday, 24 March 2013, Andrei Pozolotin 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 >> >> To: Andrei Pozolotin >> >> Cc: Maven Developers List >> , Robert >> Scholte > 'rfscholte@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 >>> To: Maven Developers List >>> 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 >>>> -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 >>>> : >>>> >>>>> 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 >>> >> >> >> -- >> Sent from my phone --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For additional commands, e-mail: dev-help@maven.apache.org