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 0D4E3FD4C for ; Wed, 27 Mar 2013 21:46:10 +0000 (UTC) Received: (qmail 54716 invoked by uid 500); 27 Mar 2013 21:46:09 -0000 Delivered-To: apmail-maven-dev-archive@maven.apache.org Received: (qmail 54573 invoked by uid 500); 27 Mar 2013 21:46:09 -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 54559 invoked by uid 99); 27 Mar 2013 21:46:09 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 27 Mar 2013 21:46:09 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of stephen.alan.connolly@gmail.com designates 209.85.212.172 as permitted sender) Received: from [209.85.212.172] (HELO mail-wi0-f172.google.com) (209.85.212.172) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 27 Mar 2013 21:46:05 +0000 Received: by mail-wi0-f172.google.com with SMTP id hr17so2760260wib.17 for ; Wed, 27 Mar 2013 14:45:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=THbXVEE7arpHVVo81XYMgU/uPrxLDYyhO3fVWjQAYpk=; b=tOE8Pd4gxfxel25iUWMUr6Gdtnsr6lkmod5+7JRxsbr9dIQOZv0Ls8euYdvJGonv23 V2ly/29IS9S1vHyCKS4RKoWkKmj8hLLUenkPRjihyl9iKGvcrVMOc1XAiJKOGSHobKxN he820QB6URVHV1vld/zJcS9dcpPivAk4liWhLTPEkeRRJhZ8acuILoQP2WpC0N8sikeU /5RAk9Ft7iXeUimShgAJ7TifkNsySE54CPktaDf02xDsHVfx2+6c7KRzaW3/xVps8Hgm Qap9TXD99vjrjBJ3U6sfIql8tPKwoNCn0Thb3qaCkWvaotZsHS7HmMRVC6bF6chU27kX db7A== MIME-Version: 1.0 X-Received: by 10.180.36.48 with SMTP id n16mr12411417wij.30.1364420743758; Wed, 27 Mar 2013 14:45:43 -0700 (PDT) Received: by 10.194.20.33 with HTTP; Wed, 27 Mar 2013 14:45:43 -0700 (PDT) In-Reply-To: References: <514F2782.8040103@gmail.com> <514F60A7.2020307@gmail.com> <514F9138.2010307@gmail.com> Date: Wed, 27 Mar 2013 21:45:43 +0000 Message-ID: Subject: Re: Multi-project releases From: Stephen Connolly To: Maven Developers List Content-Type: multipart/alternative; boundary=e89a8f502fa2c189c904d8eef51e X-Virus-Checked: Checked by ClamAV on apache.org --e89a8f502fa2c189c904d8eef51e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes I need to gr=F6k the fake SCM that people use for integration tests On Wednesday, 27 March 2013, Robert Scholte wrote: > @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 < > andrei.pozolotin@gmail.com>: > > 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 > > --=20 Sent from my phone --e89a8f502fa2c189c904d8eef51e--