You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Stephen Connolly <st...@gmail.com> on 2013/03/11 12:50:38 UTC
Multi-project releases
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
Re: Multi-project releases
Posted by Fred Cooke <fr...@gmail.com>.
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.pozolotin@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 <fr...@gmail.com> <fr...@gmail.com>
> To: Maven Developers List <de...@maven.apache.org> <de...@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 <an...@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 <st...@gmail.com> <st...@gmail.com>
> To: Andrei Pozolotin <an...@gmail.com> <an...@gmail.com>
> Cc: Maven Developers List <de...@maven.apache.org> <de...@maven.apache.org>, Robert Scholte<rf...@apache.org> <rf...@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 <rf...@apache.org> <rf...@apache.org> <javascript:_e({},
> 'cvml', 'rfscholte@apache.org');>
> To: Maven Developers List <de...@maven.apache.org> <de...@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
> <st...@gmail.com> <st...@gmail.com> <javascript:_e({}, 'cvml',
> 'stephen.alan.connolly@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-unsubscribe@maven.apache.org
> <javascript:_e({}, 'cvml', 'dev-unsubscribe@maven.apache.org');>
> For additional commands, e-mail: dev-help@maven.apache.org
> <javascript:_e({}, 'cvml', 'dev-help@maven.apache.org');>
>
>
>
> --
> Sent from my phone
>
>
>
Re: Multi-project releases
Posted by Andrei Pozolotin <an...@gmail.com>.
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 <fr...@gmail.com>
To: Maven Developers List <de...@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.pozolotin@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 <st...@gmail.com>
>> To: Andrei Pozolotin <an...@gmail.com>
>> Cc: Maven Developers List <de...@maven.apache.org>, Robert Scholte
>> <rf...@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 <rf...@apache.org> <javascript:_e({},
>>> 'cvml', 'rfscholte@apache.org');>
>>> To: Maven Developers List <de...@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
>>>> <st...@gmail.com> <javascript:_e({}, 'cvml',
>>>> 'stephen.alan.connolly@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-unsubscribe@maven.apache.org
>>>> <javascript:_e({}, 'cvml', 'dev-unsubscribe@maven.apache.org');>
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>> <javascript:_e({}, 'cvml', 'dev-help@maven.apache.org');>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> --
>>> Sent from my phone
>>
Re: Multi-project releases
Posted by Fred Cooke <fr...@gmail.com>.
>
> * 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.pozolotin@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 <st...@gmail.com>
> To: Andrei Pozolotin <an...@gmail.com>
> Cc: Maven Developers List <de...@maven.apache.org>, Robert Scholte
> <rf...@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 <rf...@apache.org> <javascript:_e({},
> > 'cvml', 'rfscholte@apache.org');>
> > To: Maven Developers List <de...@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
> >> <st...@gmail.com> <javascript:_e({}, 'cvml',
> >> 'stephen.alan.connolly@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-unsubscribe@maven.apache.org
> >> <javascript:_e({}, 'cvml', 'dev-unsubscribe@maven.apache.org');>
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >> <javascript:_e({}, 'cvml', 'dev-help@maven.apache.org');>
> >>
> >>
> >
> >
> >
> >
> >
> > --
> > Sent from my phone
>
>
Re: Multi-project releases
Posted by Stephen Connolly <st...@gmail.com>.
Yes I need to grök 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 <module> 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 <st...@gmail.com>
>> To: Andrei Pozolotin <an...@gmail.com>
>> Cc: Maven Developers List <de...@maven.apache.org>, Robert Scholte
>> <rf...@apache.org>
>> 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 <st...@gmail.com>
>>> <javascript:_e({}, 'cvml', 'stephen.alan.connolly@gmail.com');>
>>> To: Andrei Pozolotin <an...@gmail.com>
>>> <javascript:_e({}, 'cvml', 'andrei.pozolotin@gmail.com');>
>>> Cc: Maven Developers List <de...@maven.apache.org>
>>> <javascript:_e({}, 'cvml', 'dev@maven.apache.org');>, Robert
>>> Scholte <rf...@apache.org> <javascript:_e({}, 'cvml',
>>> '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<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<https://github.com/barchart/barchart-jenkins-tester-ecosystem/blob/master/readme.md>
>>>>
>>>> Andrei
>>>>
>>>> -------- Original Message --------
>>>> Subject: Re: Multi-project releases
>>>> From: Robert Scholte <rf...@apache.org>
>>>> To: Maven Developers List <de...@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<https://jira.codehaus.org/browse/MRELEASE-814>
>>>>> [2] https://jira.codehaus.org/**browse/MRELEASE-516<https://jira.codehaus.org/browse/MRELEASE-516>
>>>>>
>>>>>
>>>>> Op Mon, 11 Mar 2013 12:50:38 +0100 schreef Stephen Connolly
>>>>> <st...@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
>>>>>>
>>>>>
>>>>
>>>
>>> --
>>> Sent from my phone
>>>
>>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Sent from my phone
Re: Multi-project releases
Posted by Andrei Pozolotin <an...@gmail.com>.
*Robert:*
I actually relaxed "no module nesting" requirement. just not tested
well yet.
Thank you,
Andrei
-------- Original Message --------
Subject: Re: Multi-project releases
From: Robert Scholte <rf...@apache.org>
To: Maven Developers List <de...@maven.apache.org>
Date: Wed 27 Mar 2013 03:59:42 PM CDT
> @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
> <an...@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 <module> 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 <st...@gmail.com>
>> To: Andrei Pozolotin <an...@gmail.com>
>> Cc: Maven Developers List <de...@maven.apache.org>, Robert Scholte
>> <rf...@apache.org>
>> 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 <st...@gmail.com>
>>> <javascript:_e({}, 'cvml', 'stephen.alan.connolly@gmail.com');>
>>> To: Andrei Pozolotin <an...@gmail.com>
>>> <javascript:_e({}, 'cvml', 'andrei.pozolotin@gmail.com');>
>>> Cc: Maven Developers List <de...@maven.apache.org>
>>> <javascript:_e({}, 'cvml', 'dev@maven.apache.org');>, Robert
>>> Scholte <rf...@apache.org> <javascript:_e({}, 'cvml',
>>> '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 <rf...@apache.org>
>>>> To: Maven Developers List <de...@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
>>>>> <st...@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
>>>>
>>>
>>>
>>> --
>>> Sent from my phone
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Multi-project releases
Posted by Robert Scholte <rf...@apache.org>.
@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
<an...@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 <module> 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 <st...@gmail.com>
> To: Andrei Pozolotin <an...@gmail.com>
> Cc: Maven Developers List <de...@maven.apache.org>, Robert Scholte
> <rf...@apache.org>
> 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 <st...@gmail.com>
>> <javascript:_e({}, 'cvml', 'stephen.alan.connolly@gmail.com');>
>> To: Andrei Pozolotin <an...@gmail.com>
>> <javascript:_e({}, 'cvml', 'andrei.pozolotin@gmail.com');>
>> Cc: Maven Developers List <de...@maven.apache.org>
>> <javascript:_e({}, 'cvml', 'dev@maven.apache.org');>, Robert
>> Scholte <rf...@apache.org> <javascript:_e({}, 'cvml',
>> '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 <rf...@apache.org>
>>> To: Maven Developers List <de...@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
>>>> <st...@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
>>>
>>
>>
>> --
>> Sent from my phone
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Multi-project releases
Posted by Andrei Pozolotin <an...@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 <module> 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 <st...@gmail.com>
To: Andrei Pozolotin <an...@gmail.com>
Cc: Maven Developers List <de...@maven.apache.org>, Robert Scholte
<rf...@apache.org>
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 <st...@gmail.com>
> <javascript:_e({}, 'cvml', 'stephen.alan.connolly@gmail.com');>
> To: Andrei Pozolotin <an...@gmail.com>
> <javascript:_e({}, 'cvml', 'andrei.pozolotin@gmail.com');>
> Cc: Maven Developers List <de...@maven.apache.org>
> <javascript:_e({}, 'cvml', 'dev@maven.apache.org');>, Robert
> Scholte <rf...@apache.org> <javascript:_e({}, 'cvml',
> '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 <rf...@apache.org>
>> To: Maven Developers List <de...@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
>>> <st...@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
>>
>
>
> --
> Sent from my phone
Re: Multi-project releases
Posted by Andrei Pozolotin <an...@gmail.com>.
sharing is a key. I suggest you change your assumption to have
aggregation pom be part of the source repo
-------- Original Message --------
Subject: Re: Multi-project releases
From: Stephen Connolly <st...@gmail.com>
To: Maven Developers List <de...@maven.apache.org>
Date: Sun 24 Mar 2013 05:55:56 PM CDT
> I usually don't check them in, but they can be useful for others, so not a
> valid assumption, also I do tend to layer them as the scope if a change
> grows.
>
> On Sunday, 24 March 2013, Robert Scholte wrote:
>
>> Let me answer my own question: no, it is not the same.
>> Main difference is that your release-trees are correct, which is not the
>> case for MRELEASE-516.
>> The local-aggregator makes the difference.
>> I still have my doubts if the suggested solution is solid enough.
>> Maybe it is not the collection of release-roots we need to find, but only
>> the local-aggregator(s). All its modules are or should be release-roots by
>> definition.
>> Can we assume that the root-pom is the only local-aggregator or could one
>> of its modules also be a local-aggregator?
>> Can we assume that local-aggregators are never checked in?
>>
>> In the past I've had good discussions with Fred Cooke about multi-modules
>> in combination with the maven-release-plugin, so after sharing some
>> thoughts over the IRC-chat I asked him to join this thread.
>>
>> Robert
>>
>> Op Sun, 24 Mar 2013 22:07:51 +0100 schreef Robert Scholte <
>> rfscholte@apache.org>:
>>
>> So you actually are talking about https://jira.codehaus.org/**
>> browse/MRELEASE-516 <https://jira.codehaus.org/browse/MRELEASE-516> ?
>>
>> Robert
>>
>> Op Sun, 24 Mar 2013 21:59:40 +0100 schreef Stephen Connolly <
>> stephen.alan.connolly@gmail.com>:
>>
>> 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 <st...@gmail.com><javascript:_e({},
>> 'cvml', 'stephen.alan.connolly@gmail.com');>
>> To: Andrei Pozolotin <an...@gmail.com> <javascript:_e({},
>> 'cvml', 'andrei.pozolotin@gmail.com');>
>> Cc: Maven Developers List <de...@maven.apache.org> <javascript:_e({},
>> 'cvml', 'dev@maven.apache.org');>, Robert Scholte <rf...@apache.org><javascript:_e({},
>> 'cvml', '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<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<https://github.com/barchart/barchart-jenkins-tester-ecosystem/blob/master/readme.md>
>>
>> Andrei
>>
>> -------- Original Message --------
>> Subject: Re: Multi-project releases
>> From: Robert Scholte <rf...@apache.org>
>> To: Maven Developers List <de...@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
>>
>>
Re: Multi-project releases
Posted by Stephen Connolly <st...@gmail.com>.
I usually don't check them in, but they can be useful for others, so not a
valid assumption, also I do tend to layer them as the scope if a change
grows.
On Sunday, 24 March 2013, Robert Scholte wrote:
> Let me answer my own question: no, it is not the same.
> Main difference is that your release-trees are correct, which is not the
> case for MRELEASE-516.
> The local-aggregator makes the difference.
> I still have my doubts if the suggested solution is solid enough.
> Maybe it is not the collection of release-roots we need to find, but only
> the local-aggregator(s). All its modules are or should be release-roots by
> definition.
> Can we assume that the root-pom is the only local-aggregator or could one
> of its modules also be a local-aggregator?
> Can we assume that local-aggregators are never checked in?
>
> In the past I've had good discussions with Fred Cooke about multi-modules
> in combination with the maven-release-plugin, so after sharing some
> thoughts over the IRC-chat I asked him to join this thread.
>
> Robert
>
> Op Sun, 24 Mar 2013 22:07:51 +0100 schreef Robert Scholte <
> rfscholte@apache.org>:
>
> So you actually are talking about https://jira.codehaus.org/**
> browse/MRELEASE-516 <https://jira.codehaus.org/browse/MRELEASE-516> ?
>
> Robert
>
> Op Sun, 24 Mar 2013 21:59:40 +0100 schreef Stephen Connolly <
> stephen.alan.connolly@gmail.com>:
>
> 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 <st...@gmail.com><javascript:_e({},
> 'cvml', 'stephen.alan.connolly@gmail.com');>
> To: Andrei Pozolotin <an...@gmail.com> <javascript:_e({},
> 'cvml', 'andrei.pozolotin@gmail.com');>
> Cc: Maven Developers List <de...@maven.apache.org> <javascript:_e({},
> 'cvml', 'dev@maven.apache.org');>, Robert Scholte <rf...@apache.org><javascript:_e({},
> 'cvml', '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<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<https://github.com/barchart/barchart-jenkins-tester-ecosystem/blob/master/readme.md>
>
> Andrei
>
> -------- Original Message --------
> Subject: Re: Multi-project releases
> From: Robert Scholte <rf...@apache.org>
> To: Maven Developers List <de...@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
>
>
--
Sent from my phone
Re: Multi-project releases
Posted by Andrei Pozolotin <an...@gmail.com>.
is there a way to designate local-aggregator poms as such? say, have
version = 0.0.0, since they are never released.
-------- Original Message --------
Subject: Re: Multi-project releases
From: Robert Scholte <rf...@apache.org>
To: Maven Developers List <de...@maven.apache.org>
Date: Sun 24 Mar 2013 04:44:20 PM CDT
> Let me answer my own question: no, it is not the same.
> Main difference is that your release-trees are correct, which is not
> the case for MRELEASE-516.
> The local-aggregator makes the difference.
> I still have my doubts if the suggested solution is solid enough.
> Maybe it is not the collection of release-roots we need to find, but
> only the local-aggregator(s). All its modules are or should be
> release-roots by definition.
> Can we assume that the root-pom is the only local-aggregator or could
> one of its modules also be a local-aggregator?
> Can we assume that local-aggregators are never checked in?
>
> In the past I've had good discussions with Fred Cooke about
> multi-modules in combination with the maven-release-plugin, so after
> sharing some thoughts over the IRC-chat I asked him to join this thread.
>
> Robert
>
> Op Sun, 24 Mar 2013 22:07:51 +0100 schreef Robert Scholte
> <rf...@apache.org>:
>
>> So you actually are talking about
>> https://jira.codehaus.org/browse/MRELEASE-516 ?
>>
>> Robert
>>
>> Op Sun, 24 Mar 2013 21:59:40 +0100 schreef Stephen Connolly
>> <st...@gmail.com>:
>>
>>> 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
>>>> <st...@gmail.com><javascript:_e({}, 'cvml',
>>>> 'stephen.alan.connolly@gmail.com');>
>>>> To: Andrei Pozolotin <an...@gmail.com> <javascript:_e({},
>>>> 'cvml', 'andrei.pozolotin@gmail.com');>
>>>> Cc: Maven Developers List <de...@maven.apache.org> <javascript:_e({},
>>>> 'cvml', 'dev@maven.apache.org');>, Robert Scholte
>>>> <rf...@apache.org><javascript:_e({}, 'cvml',
>>>> '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 <rf...@apache.org>
>>>> To: Maven Developers List <de...@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
>>>> <st...@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
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Multi-project releases
Posted by Robert Scholte <rf...@apache.org>.
Let me answer my own question: no, it is not the same.
Main difference is that your release-trees are correct, which is not the
case for MRELEASE-516.
The local-aggregator makes the difference.
I still have my doubts if the suggested solution is solid enough.
Maybe it is not the collection of release-roots we need to find, but only
the local-aggregator(s). All its modules are or should be release-roots by
definition.
Can we assume that the root-pom is the only local-aggregator or could one
of its modules also be a local-aggregator?
Can we assume that local-aggregators are never checked in?
In the past I've had good discussions with Fred Cooke about multi-modules
in combination with the maven-release-plugin, so after sharing some
thoughts over the IRC-chat I asked him to join this thread.
Robert
Op Sun, 24 Mar 2013 22:07:51 +0100 schreef Robert Scholte
<rf...@apache.org>:
> So you actually are talking about
> https://jira.codehaus.org/browse/MRELEASE-516 ?
>
> Robert
>
> Op Sun, 24 Mar 2013 21:59:40 +0100 schreef Stephen Connolly
> <st...@gmail.com>:
>
>> 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
>>> <st...@gmail.com><javascript:_e({}, 'cvml',
>>> 'stephen.alan.connolly@gmail.com');>
>>> To: Andrei Pozolotin <an...@gmail.com> <javascript:_e({},
>>> 'cvml', 'andrei.pozolotin@gmail.com');>
>>> Cc: Maven Developers List <de...@maven.apache.org> <javascript:_e({},
>>> 'cvml', 'dev@maven.apache.org');>, Robert Scholte
>>> <rf...@apache.org><javascript:_e({}, 'cvml',
>>> '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 <rf...@apache.org>
>>> To: Maven Developers List <de...@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
>>> <st...@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
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Multi-project releases
Posted by Robert Scholte <rf...@apache.org>.
So you actually are talking about
https://jira.codehaus.org/browse/MRELEASE-516 ?
Robert
Op Sun, 24 Mar 2013 21:59:40 +0100 schreef Stephen Connolly
<st...@gmail.com>:
> 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
>> <st...@gmail.com><javascript:_e({}, 'cvml',
>> 'stephen.alan.connolly@gmail.com');>
>> To: Andrei Pozolotin <an...@gmail.com> <javascript:_e({},
>> 'cvml', 'andrei.pozolotin@gmail.com');>
>> Cc: Maven Developers List <de...@maven.apache.org> <javascript:_e({},
>> 'cvml', 'dev@maven.apache.org');>, Robert Scholte
>> <rf...@apache.org><javascript:_e({}, 'cvml',
>> '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 <rf...@apache.org>
>> To: Maven Developers List <de...@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
>> <st...@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
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Multi-project releases
Posted by Stephen Connolly <st...@gmail.com>.
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 <st...@gmail.com><javascript:_e({}, 'cvml', 'stephen.alan.connolly@gmail.com');>
> To: Andrei Pozolotin <an...@gmail.com> <javascript:_e({},
> 'cvml', 'andrei.pozolotin@gmail.com');>
> Cc: Maven Developers List <de...@maven.apache.org> <javascript:_e({},
> 'cvml', 'dev@maven.apache.org');>, Robert Scholte <rf...@apache.org><javascript:_e({}, 'cvml', '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 <rf...@apache.org>
> To: Maven Developers List <de...@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
> <st...@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
>
>
--
Sent from my phone
Re: Multi-project releases
Posted by Andrei Pozolotin <an...@gmail.com>.
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 <st...@gmail.com>
To: Andrei Pozolotin <an...@gmail.com>
Cc: Maven Developers List <de...@maven.apache.org>, Robert Scholte
<rf...@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 <rf...@apache.org> <javascript:_e({},
> 'cvml', 'rfscholte@apache.org');>
> To: Maven Developers List <de...@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
>> <st...@gmail.com> <javascript:_e({}, 'cvml',
>> 'stephen.alan.connolly@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-unsubscribe@maven.apache.org
>> <javascript:_e({}, 'cvml', 'dev-unsubscribe@maven.apache.org');>
>> For additional commands, e-mail: dev-help@maven.apache.org
>> <javascript:_e({}, 'cvml', 'dev-help@maven.apache.org');>
>>
>>
>
>
>
>
>
> --
> Sent from my phone
Re: Multi-project releases
Posted by Fred Cooke <fr...@gmail.com>.
I'm late to the party here, tonight, but can we clarify what a "multi
project release" is? is it a multi module release? or something more like
continuous release?
As for "needs release" how can this be automatically determined? This seems
fundamentally human to me? Or do you simply mean "dependency on snapshot of
some project, find that project, release it, update dep to point at
arbitrary release" ?
Thanks for the heads upon this thread via IRC, appreciated!
Regards,
Fred.
On Sun, Mar 24, 2013 at 8:32 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> 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 <rf...@apache.org> <javascript:_e({}, 'cvml',
> > 'rfscholte@apache.org');>
> > To: Maven Developers List <de...@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
> > <st...@gmail.com> <javascript:_e({}, 'cvml',
> > 'stephen.alan.connolly@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-unsubscribe@maven.apache.org<javascript:_e({},
> 'cvml', 'dev-unsubscribe@maven.apache.org');>
> > For additional commands, e-mail: dev-help@maven.apache.org<javascript:_e({},
> 'cvml', 'dev-help@maven.apache.org');>
> >
> >
> >
> >
>
>
>
> --
> Sent from my phone
>
Re: Multi-project releases
Posted by Stephen Connolly <st...@gmail.com>.
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 <rf...@apache.org> <javascript:_e({}, 'cvml',
> 'rfscholte@apache.org');>
> To: Maven Developers List <de...@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
> <st...@gmail.com> <javascript:_e({}, 'cvml',
> 'stephen.alan.connolly@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-unsubscribe@maven.apache.org<javascript:_e({}, 'cvml', 'dev-unsubscribe@maven.apache.org');>
> For additional commands, e-mail: dev-help@maven.apache.org<javascript:_e({}, 'cvml', 'dev-help@maven.apache.org');>
>
>
>
>
--
Sent from my phone
Re: Multi-project releases
Posted by Jeff Jensen <je...@upstairstechnology.com>.
Yes, good point to know of in case that causes a problem.
On Sun, Mar 24, 2013 at 2:30 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> That's still going to result in all the children being part of the tag
> though
>
> On Sunday, 24 March 2013, Jeff Jensen wrote:
>
> > -N
> > Same for other operations to not recurse into children/modules.
> >
> >
> > On Sun, Mar 24, 2013 at 11:55 AM, Andrei Pozolotin <
> > andrei.pozolotin@gmail.com <javascript:;>> wrote:
> >
> > > *Robert*
> > >
> > > unrelated question, may be you can clarify: in the current
> > > maven-release-plugin
> > > what is the way to release parent w/o releasing its modules?
> > >
> > > Thank you,
> > >
> > > Andrei
> > >
> > > -------- Original Message --------
> > > Subject: Re: Multi-project releases
> > > From: Robert Scholte <rf...@apache.org>
> > > To: Maven Developers List <de...@maven.apache.org>, Andrei Pozolotin
> > > <an...@gmail.com>
> > > Cc: "Stephen Connolly" <st...@gmail.com>
> > > Date: Sun 24 Mar 2013 11:36:04 AM CDT
> > > > Andrei,
> > > >
> > > > First of all I'm only talking about the definition of root project,
> > > > not about release stuff yet, because this has already consequences
> for
> > > > other plugins as well.
> > > > Please verify the ProjectUtils.isRootProject( MavenProject ) [1]. You
> > > > should see that it does match your "start-from-any-module".
> > > > If this will be the component for plugins (and maybe other projects)
> > > > which contains the actual definitions and transformations, we have a
> > > > good place to document it and to refer to.
> > > >
> > > > Robert
> > > >
> > > > [1]
> > > >
> > >
> >
> http://svn.apache.org/viewvc/maven/shared/trunk/maven-project-utils/src/main/java/org/apache/maven/shared/project/utils/ProjectUtils.java?view=markup&#l39
> > > >
> > > >
> > > > Op Sun, 24 Mar 2013 17:19:14 +0100 schreef Andrei Pozolotin
> > > > <an...@gmail.com>:
> > > >
> > > >> 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 <rf...@apache.org>
> > > >> To: Maven Developers List <de...@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"
>
>
>
> --
> Sent from my phone
>
Re: Multi-project releases
Posted by Andrei Pozolotin <an...@gmail.com>.
Jeff got it, thank you. Andrei
-------- Original Message --------
Subject: Re: Multi-project releases
From: Jeff Jensen <je...@upstairstechnology.com>
To: Maven Developers List <de...@maven.apache.org>
Date: Sun 24 Mar 2013 04:00:28 PM CDT
> I am not aware of a Maven feature to fully ignore them other than -N with
> the tag caveat. When I've done what you asked, I did not miss a Maven
> feature to do so. You could temporarily move the module dirs or release
> the parent in a new location without the modules (-N is still your friend
> to accomplish that so Maven does not try to process the listed modules).
> Depending how you release (e.g. manually, via CI job), having a release
> area separate from the dev area is a good idea anyway to prevent hassles
> with your dev work (while release plugin prevents releasing with
> uncommitted work, it's nice to not have to worry about *anything* by
> performing release in a clean area - a release CI job or separate local
> checkout).
>
>
>
> On Sun, Mar 24, 2013 at 3:24 PM, Andrei Pozolotin <
> andrei.pozolotin@gmail.com> wrote:
>
>> I do not mind - "children being part of the tag ".
>>
>> so what is the way to release a parent w/o its modules?
>>
>> -------- Original Message --------
>> Subject: Re: Multi-project releases
>> From: Stephen Connolly <st...@gmail.com>
>> To: Maven Developers List <de...@maven.apache.org>
>> Date: Sun 24 Mar 2013 02:30:10 PM CDT
>>> That's still going to result in all the children being part of the tag
>>> though
>>>
>>> On Sunday, 24 March 2013, Jeff Jensen wrote:
>>>
>>>> -N
>>>> Same for other operations to not recurse into children/modules.
>>>>
>>>>
>>>> On Sun, Mar 24, 2013 at 11:55 AM, Andrei Pozolotin <
>>>> andrei.pozolotin@gmail.com <javascript:;>> wrote:
>>>>
>>>>> *Robert*
>>>>>
>>>>> unrelated question, may be you can clarify: in the current
>>>>> maven-release-plugin
>>>>> what is the way to release parent w/o releasing its modules?
>>>>>
>>>>> Thank you,
>>>>>
>>>>> Andrei
>>>>>
>>>>> -------- Original Message --------
>>>>> Subject: Re: Multi-project releases
>>>>> From: Robert Scholte <rf...@apache.org>
>>>>> To: Maven Developers List <de...@maven.apache.org>, Andrei Pozolotin
>>>>> <an...@gmail.com>
>>>>> Cc: "Stephen Connolly" <st...@gmail.com>
>>>>> Date: Sun 24 Mar 2013 11:36:04 AM CDT
>>>>>> Andrei,
>>>>>>
>>>>>> First of all I'm only talking about the definition of root project,
>>>>>> not about release stuff yet, because this has already consequences for
>>>>>> other plugins as well.
>>>>>> Please verify the ProjectUtils.isRootProject( MavenProject ) [1]. You
>>>>>> should see that it does match your "start-from-any-module".
>>>>>> If this will be the component for plugins (and maybe other projects)
>>>>>> which contains the actual definitions and transformations, we have a
>>>>>> good place to document it and to refer to.
>>>>>>
>>>>>> Robert
>>>>>>
>>>>>> [1]
>>>>>>
>> http://svn.apache.org/viewvc/maven/shared/trunk/maven-project-utils/src/main/java/org/apache/maven/shared/project/utils/ProjectUtils.java?view=markup&#l39
>>>>>> Op Sun, 24 Mar 2013 17:19:14 +0100 schreef Andrei Pozolotin
>>>>>> <an...@gmail.com>:
>>>>>>
>>>>>>> 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 <rf...@apache.org>
>>>>>>> To: Maven Developers List <de...@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"
>>>
>>
Re: Multi-project releases
Posted by Jeff Jensen <je...@upstairstechnology.com>.
I am not aware of a Maven feature to fully ignore them other than -N with
the tag caveat. When I've done what you asked, I did not miss a Maven
feature to do so. You could temporarily move the module dirs or release
the parent in a new location without the modules (-N is still your friend
to accomplish that so Maven does not try to process the listed modules).
Depending how you release (e.g. manually, via CI job), having a release
area separate from the dev area is a good idea anyway to prevent hassles
with your dev work (while release plugin prevents releasing with
uncommitted work, it's nice to not have to worry about *anything* by
performing release in a clean area - a release CI job or separate local
checkout).
On Sun, Mar 24, 2013 at 3:24 PM, Andrei Pozolotin <
andrei.pozolotin@gmail.com> wrote:
> I do not mind - "children being part of the tag ".
>
> so what is the way to release a parent w/o its modules?
>
> -------- Original Message --------
> Subject: Re: Multi-project releases
> From: Stephen Connolly <st...@gmail.com>
> To: Maven Developers List <de...@maven.apache.org>
> Date: Sun 24 Mar 2013 02:30:10 PM CDT
> > That's still going to result in all the children being part of the tag
> > though
> >
> > On Sunday, 24 March 2013, Jeff Jensen wrote:
> >
> >> -N
> >> Same for other operations to not recurse into children/modules.
> >>
> >>
> >> On Sun, Mar 24, 2013 at 11:55 AM, Andrei Pozolotin <
> >> andrei.pozolotin@gmail.com <javascript:;>> wrote:
> >>
> >>> *Robert*
> >>>
> >>> unrelated question, may be you can clarify: in the current
> >>> maven-release-plugin
> >>> what is the way to release parent w/o releasing its modules?
> >>>
> >>> Thank you,
> >>>
> >>> Andrei
> >>>
> >>> -------- Original Message --------
> >>> Subject: Re: Multi-project releases
> >>> From: Robert Scholte <rf...@apache.org>
> >>> To: Maven Developers List <de...@maven.apache.org>, Andrei Pozolotin
> >>> <an...@gmail.com>
> >>> Cc: "Stephen Connolly" <st...@gmail.com>
> >>> Date: Sun 24 Mar 2013 11:36:04 AM CDT
> >>>> Andrei,
> >>>>
> >>>> First of all I'm only talking about the definition of root project,
> >>>> not about release stuff yet, because this has already consequences for
> >>>> other plugins as well.
> >>>> Please verify the ProjectUtils.isRootProject( MavenProject ) [1]. You
> >>>> should see that it does match your "start-from-any-module".
> >>>> If this will be the component for plugins (and maybe other projects)
> >>>> which contains the actual definitions and transformations, we have a
> >>>> good place to document it and to refer to.
> >>>>
> >>>> Robert
> >>>>
> >>>> [1]
> >>>>
> >>
> http://svn.apache.org/viewvc/maven/shared/trunk/maven-project-utils/src/main/java/org/apache/maven/shared/project/utils/ProjectUtils.java?view=markup&#l39
> >>>>
> >>>> Op Sun, 24 Mar 2013 17:19:14 +0100 schreef Andrei Pozolotin
> >>>> <an...@gmail.com>:
> >>>>
> >>>>> 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 <rf...@apache.org>
> >>>>> To: Maven Developers List <de...@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"
> >
> >
>
>
Re: Multi-project releases
Posted by Andrei Pozolotin <an...@gmail.com>.
I do not mind - "children being part of the tag ".
so what is the way to release a parent w/o its modules?
-------- Original Message --------
Subject: Re: Multi-project releases
From: Stephen Connolly <st...@gmail.com>
To: Maven Developers List <de...@maven.apache.org>
Date: Sun 24 Mar 2013 02:30:10 PM CDT
> That's still going to result in all the children being part of the tag
> though
>
> On Sunday, 24 March 2013, Jeff Jensen wrote:
>
>> -N
>> Same for other operations to not recurse into children/modules.
>>
>>
>> On Sun, Mar 24, 2013 at 11:55 AM, Andrei Pozolotin <
>> andrei.pozolotin@gmail.com <javascript:;>> wrote:
>>
>>> *Robert*
>>>
>>> unrelated question, may be you can clarify: in the current
>>> maven-release-plugin
>>> what is the way to release parent w/o releasing its modules?
>>>
>>> Thank you,
>>>
>>> Andrei
>>>
>>> -------- Original Message --------
>>> Subject: Re: Multi-project releases
>>> From: Robert Scholte <rf...@apache.org>
>>> To: Maven Developers List <de...@maven.apache.org>, Andrei Pozolotin
>>> <an...@gmail.com>
>>> Cc: "Stephen Connolly" <st...@gmail.com>
>>> Date: Sun 24 Mar 2013 11:36:04 AM CDT
>>>> Andrei,
>>>>
>>>> First of all I'm only talking about the definition of root project,
>>>> not about release stuff yet, because this has already consequences for
>>>> other plugins as well.
>>>> Please verify the ProjectUtils.isRootProject( MavenProject ) [1]. You
>>>> should see that it does match your "start-from-any-module".
>>>> If this will be the component for plugins (and maybe other projects)
>>>> which contains the actual definitions and transformations, we have a
>>>> good place to document it and to refer to.
>>>>
>>>> Robert
>>>>
>>>> [1]
>>>>
>> http://svn.apache.org/viewvc/maven/shared/trunk/maven-project-utils/src/main/java/org/apache/maven/shared/project/utils/ProjectUtils.java?view=markup&#l39
>>>>
>>>> Op Sun, 24 Mar 2013 17:19:14 +0100 schreef Andrei Pozolotin
>>>> <an...@gmail.com>:
>>>>
>>>>> 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 <rf...@apache.org>
>>>>> To: Maven Developers List <de...@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"
>
>
Re: Multi-project releases
Posted by Stephen Connolly <st...@gmail.com>.
That's still going to result in all the children being part of the tag
though
On Sunday, 24 March 2013, Jeff Jensen wrote:
> -N
> Same for other operations to not recurse into children/modules.
>
>
> On Sun, Mar 24, 2013 at 11:55 AM, Andrei Pozolotin <
> andrei.pozolotin@gmail.com <javascript:;>> wrote:
>
> > *Robert*
> >
> > unrelated question, may be you can clarify: in the current
> > maven-release-plugin
> > what is the way to release parent w/o releasing its modules?
> >
> > Thank you,
> >
> > Andrei
> >
> > -------- Original Message --------
> > Subject: Re: Multi-project releases
> > From: Robert Scholte <rf...@apache.org>
> > To: Maven Developers List <de...@maven.apache.org>, Andrei Pozolotin
> > <an...@gmail.com>
> > Cc: "Stephen Connolly" <st...@gmail.com>
> > Date: Sun 24 Mar 2013 11:36:04 AM CDT
> > > Andrei,
> > >
> > > First of all I'm only talking about the definition of root project,
> > > not about release stuff yet, because this has already consequences for
> > > other plugins as well.
> > > Please verify the ProjectUtils.isRootProject( MavenProject ) [1]. You
> > > should see that it does match your "start-from-any-module".
> > > If this will be the component for plugins (and maybe other projects)
> > > which contains the actual definitions and transformations, we have a
> > > good place to document it and to refer to.
> > >
> > > Robert
> > >
> > > [1]
> > >
> >
> http://svn.apache.org/viewvc/maven/shared/trunk/maven-project-utils/src/main/java/org/apache/maven/shared/project/utils/ProjectUtils.java?view=markup&#l39
> > >
> > >
> > > Op Sun, 24 Mar 2013 17:19:14 +0100 schreef Andrei Pozolotin
> > > <an...@gmail.com>:
> > >
> > >> 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 <rf...@apache.org>
> > >> To: Maven Developers List <de...@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"
--
Sent from my phone
Re: Multi-project releases
Posted by Jeff Jensen <je...@upstairstechnology.com>.
-N
Same for other operations to not recurse into children/modules.
On Sun, Mar 24, 2013 at 11:55 AM, Andrei Pozolotin <
andrei.pozolotin@gmail.com> wrote:
> *Robert*
>
> unrelated question, may be you can clarify: in the current
> maven-release-plugin
> what is the way to release parent w/o releasing its modules?
>
> Thank you,
>
> Andrei
>
> -------- Original Message --------
> Subject: Re: Multi-project releases
> From: Robert Scholte <rf...@apache.org>
> To: Maven Developers List <de...@maven.apache.org>, Andrei Pozolotin
> <an...@gmail.com>
> Cc: "Stephen Connolly" <st...@gmail.com>
> Date: Sun 24 Mar 2013 11:36:04 AM CDT
> > Andrei,
> >
> > First of all I'm only talking about the definition of root project,
> > not about release stuff yet, because this has already consequences for
> > other plugins as well.
> > Please verify the ProjectUtils.isRootProject( MavenProject ) [1]. You
> > should see that it does match your "start-from-any-module".
> > If this will be the component for plugins (and maybe other projects)
> > which contains the actual definitions and transformations, we have a
> > good place to document it and to refer to.
> >
> > Robert
> >
> > [1]
> >
> http://svn.apache.org/viewvc/maven/shared/trunk/maven-project-utils/src/main/java/org/apache/maven/shared/project/utils/ProjectUtils.java?view=markup&#l39
> >
> >
> > Op Sun, 24 Mar 2013 17:19:14 +0100 schreef Andrei Pozolotin
> > <an...@gmail.com>:
> >
> >> 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 <rf...@apache.org>
> >> To: Maven Developers List <de...@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
> >>> <st...@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-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>>
> >
>
>
Re: Multi-project releases
Posted by Andrei Pozolotin <an...@gmail.com>.
*Robert*
unrelated question, may be you can clarify: in the current
maven-release-plugin
what is the way to release parent w/o releasing its modules?
Thank you,
Andrei
-------- Original Message --------
Subject: Re: Multi-project releases
From: Robert Scholte <rf...@apache.org>
To: Maven Developers List <de...@maven.apache.org>, Andrei Pozolotin
<an...@gmail.com>
Cc: "Stephen Connolly" <st...@gmail.com>
Date: Sun 24 Mar 2013 11:36:04 AM CDT
> Andrei,
>
> First of all I'm only talking about the definition of root project,
> not about release stuff yet, because this has already consequences for
> other plugins as well.
> Please verify the ProjectUtils.isRootProject( MavenProject ) [1]. You
> should see that it does match your "start-from-any-module".
> If this will be the component for plugins (and maybe other projects)
> which contains the actual definitions and transformations, we have a
> good place to document it and to refer to.
>
> Robert
>
> [1]
> http://svn.apache.org/viewvc/maven/shared/trunk/maven-project-utils/src/main/java/org/apache/maven/shared/project/utils/ProjectUtils.java?view=markup&#l39
>
>
> Op Sun, 24 Mar 2013 17:19:14 +0100 schreef Andrei Pozolotin
> <an...@gmail.com>:
>
>> 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 <rf...@apache.org>
>> To: Maven Developers List <de...@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
>>> <st...@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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>
Re: Multi-project releases
Posted by Andrei Pozolotin <an...@gmail.com>.
*Robert*
what I am trying to say is that I can not really understand whether
the following make sense
Returns {@code true} if this project has no parent, or it has a
parent but isn't one of its modules
isRootProject( MavenProject project )
unless I see how it will be used by a release-like plugin. well,
never mind, I guess it is too early for questions.
Thank you,
Andrei
-------- Original Message --------
Subject: Re: Multi-project releases
From: Robert Scholte <rf...@apache.org>
To: Maven Developers List <de...@maven.apache.org>, Andrei Pozolotin
<an...@gmail.com>
Cc: "Stephen Connolly" <st...@gmail.com>
Date: Sun 24 Mar 2013 11:36:04 AM CDT
> Andrei,
>
> First of all I'm only talking about the definition of root project,
> not about release stuff yet, because this has already consequences for
> other plugins as well.
> Please verify the ProjectUtils.isRootProject( MavenProject ) [1]. You
> should see that it does match your "start-from-any-module".
> If this will be the component for plugins (and maybe other projects)
> which contains the actual definitions and transformations, we have a
> good place to document it and to refer to.
>
> Robert
>
> [1]
> http://svn.apache.org/viewvc/maven/shared/trunk/maven-project-utils/src/main/java/org/apache/maven/shared/project/utils/ProjectUtils.java?view=markup&#l39
>
>
> Op Sun, 24 Mar 2013 17:19:14 +0100 schreef Andrei Pozolotin
> <an...@gmail.com>:
>
>> 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 <rf...@apache.org>
>> To: Maven Developers List <de...@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
>>> <st...@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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>
Re: Multi-project releases
Posted by Robert Scholte <rf...@apache.org>.
Andrei,
First of all I'm only talking about the definition of root project, not
about release stuff yet, because this has already consequences for other
plugins as well.
Please verify the ProjectUtils.isRootProject( MavenProject ) [1]. You
should see that it does match your "start-from-any-module".
If this will be the component for plugins (and maybe other projects) which
contains the actual definitions and transformations, we have a good place
to document it and to refer to.
Robert
[1]
http://svn.apache.org/viewvc/maven/shared/trunk/maven-project-utils/src/main/java/org/apache/maven/shared/project/utils/ProjectUtils.java?view=markup&#l39
Op Sun, 24 Mar 2013 17:19:14 +0100 schreef Andrei Pozolotin
<an...@gmail.com>:
> 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 <rf...@apache.org>
> To: Maven Developers List <de...@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
>> <st...@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Multi-project releases
Posted by Andrei Pozolotin <an...@gmail.com>.
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 <rf...@apache.org>
To: Maven Developers List <de...@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
> <st...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Multi-project releases
Posted by Stephen Connolly <st...@gmail.com>.
Well I see a release root as being where there is a non-inherited SCM....
If there are changes since the last release (or no last release) then it
*should*/*could* be released which is what that plugin reports.
More interesting to me would be if a child project defines SCM that is
identical to the "effective" from the parent (or from the aggregator if it
were a parent) then that should not be a release root... In short I am
trying to find directories where it is intended that one runs the release
plugin to release a chunk of the reactor.
On Sunday, 24 March 2013, Robert Scholte wrote:
> 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<https://jira.codehaus.org/browse/MRELEASE-814>
> [2] https://jira.codehaus.org/**browse/MRELEASE-516<https://jira.codehaus.org/browse/MRELEASE-516>
>
>
> Op Mon, 11 Mar 2013 12:50:38 +0100 schreef Stephen Connolly <
> stephen.alan.connolly@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Sent from my phone
Re: Multi-project releases
Posted by Robert Scholte <rf...@apache.org>.
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
<st...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Multi-project releases
Posted by Andrei Pozolotin <an...@gmail.com>.
*Stephen*
1) great. lets collaborate on your plugin.
in the end, I do not care how it works, 100% maven or maven + jenkins.
2) do you know about other initiatives to address this issue?
3) do you know of a way to relax maven-release-plugin so
it does not always release children with parent.
(i.e. I want to release parent of multi-module project w/o children)
Thank you,
Andrei
-------- Original Message --------
Subject: Re: Multi-project releases
From: Stephen Connolly <st...@gmail.com>
To: Andrei Pozolotin <an...@gmail.com>
Cc: Maven Developers List <de...@maven.apache.org>
Date: Mon 11 Mar 2013 10:32:45 AM CDT
> Well with my Maven hat on, I don't like that it requires Jenkins nor
> that it is (most likely from a quick look) using the (IMPO
> fundamentally broken) Maven Project type for jobs
>
> But in essence I envision a Maven plugin with a similar end-goal...
> just not yet confident enough of my logic for detecting downstream
> projects. I think my logic for detecting release roots is sound
> though. (although it probably fails for some of the maven plugins @
> asf as they can inherit their SCM even though they are released
> independently... might be worth checking for some other explicit markers)
>
>
> On 11 March 2013 14:18, Andrei Pozolotin <andrei.pozolotin@gmail.com
> <ma...@gmail.com>> wrote:
>
> *Stephen**
> *
> I made this solution for the problem:
> https://github.com/barchart/barchart-jenkins-cascade-plugin/wiki
>
> Please let me know what you think?
>
> Thank you,
>
> Andrei
>
> -------- Original Message --------
> Subject: Multi-project releases
> From: Stephen Connolly <st...@gmail.com>
> <ma...@gmail.com>
> To: Maven Developers List <de...@maven.apache.org>
> <ma...@maven.apache.org>
> Date: Mon 11 Mar 2013 06:50:38 AM CDT
>> 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
>>
>
>
Re: Multi-project releases
Posted by Stephen Connolly <st...@gmail.com>.
Well with my Maven hat on, I don't like that it requires Jenkins nor that
it is (most likely from a quick look) using the (IMPO fundamentally broken)
Maven Project type for jobs
But in essence I envision a Maven plugin with a similar end-goal... just
not yet confident enough of my logic for detecting downstream projects. I
think my logic for detecting release roots is sound though. (although it
probably fails for some of the maven plugins @ asf as they can inherit
their SCM even though they are released independently... might be worth
checking for some other explicit markers)
On 11 March 2013 14:18, Andrei Pozolotin <an...@gmail.com> wrote:
> * Stephen**
> *
> I made this solution for the problem:
> https://github.com/barchart/barchart-jenkins-cascade-plugin/wiki
>
> Please let me know what you think?
>
> Thank you,
>
> Andrei
>
> -------- Original Message --------
> Subject: Multi-project releases
> From: Stephen Connolly <st...@gmail.com>
> To: Maven Developers List <de...@maven.apache.org> <de...@maven.apache.org>
> Date: Mon 11 Mar 2013 06:50:38 AM CDT
>
> 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
>
>
>
>
Re: Multi-project releases
Posted by Andrei Pozolotin <an...@gmail.com>.
*Stephen**
*
I made this solution for the problem:
https://github.com/barchart/barchart-jenkins-cascade-plugin/wiki
Please let me know what you think?
Thank you,
Andrei
-------- Original Message --------
Subject: Multi-project releases
From: Stephen Connolly <st...@gmail.com>
To: Maven Developers List <de...@maven.apache.org>
Date: Mon 11 Mar 2013 06:50:38 AM CDT
> 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
>
Re: Multi-project releases
Posted by Robert Scholte <rf...@apache.org>.
Hi,
I've made a start, see http://svn.apache.org/r1460347
There are IT's for resolving the site URL, for SCM URLs it should be more
of the same.
It's open for discussion.
Robert
Op Fri, 15 Mar 2013 05:14:00 +0100 schreef Rahul Thakur
<ra...@gmail.com>:
>
> And something like a CI server can make use of this capability as well.
>
>
>
> On 3/15/2013 2:20 AM, Robert Scholte wrote:
>> At least the maven-help-plugin and probably the maven-site-plugin too.
>> There's a small difference between the resolved pom for Maven(core) and
>> the way paths are transformed for the maven-release-plugin and
>> maven-site-plugin.
>>
>> here are some examples:
>> https://jira.codehaus.org/browse/MSITE-669
>> https://jira.codehaus.org/browse/MSITE-672
>> https://jira.codehaus.org/browse/MSITE-657
>>
>> Probably all URLs of distributionManagement are transformed for
>> children, but that's not exposed with the help:effective-pom.
>>
>> Robert
>>
>> Op Thu, 14 Mar 2013 21:35:15 +0100 schreef Stephen Connolly
>> <st...@gmail.com>:
>>
>>> On Thursday, 14 March 2013, Robert Scholte wrote:
>>>
>>>> Let's create a new shared component[1] for it: there are more plugins
>>>> depending on this intelligence.
>>>
>>>
>>> What other plugins could be concerned with knowing which projects are
>>> roots
>>> for the release plugin?
>>>
>>> Or maybe you gave something else in mind?
>>>
>>>
>>>> Looks to me there's no component for this kind of stuff yet.
>>>>
>>>> Robert
>>>>
>>>> [1]
>>>> http://maven.apache.org/**shared/index.html<http://maven.apache.org/shared/index.html>
>>>>
>>>>
>>>> Op Thu, 14 Mar 2013 10:32:26 +0100 schreef Stephen Connolly <
>>>> stephen.alan.connolly@gmail.com>:
>>>>
>>>> No it makes more sense in the release plugin
>>>>>
>>>>>
>>>>> On 14 March 2013 09:16, Rahul Thakur <ra...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>
>>>>>> And perhaps this capability can reside in Maven core? Just a
>>>>>> thought....
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 3/12/2013 2:56 AM, Robert Scholte wrote:
>>>>>>
>>>>>> Hi,
>>>>>>>
>>>>>>> There are several MSITE/DOXIA and MRELEASE issues related to this
>>>>>>> subject.
>>>>>>>
>>>>>>> For the SCM-section and the site-section of the
>>>>>>> distributionManagement
>>>>>>> we
>>>>>>> need a more intelligent way to resolve this.
>>>>>>> Right now this logic is hidden inside the maven-release-plugin and
>>>>>>> maven-site-plugin, causing a different result when resolved as
>>>>>>> effective-pom, so IMO it is resolved at the wrong place.
>>>>>>> They way it should be resolved depends on the type of MavenProject:
>>>>>>>
>>>>>>> - aggregator (I'm not the parent of my modules)
>>>>>>> - multimodule-root (I'm the parent of modules)
>>>>>>> - module (I'm a module of my parent)
>>>>>>> - standalone (I'm not a module of my parent/I don't have a parent
>>>>>>> or
>>>>>>> modules)
>>>>>>>
>>>>>>> IMO modules should by default expand their parents path.
>>>>>>>
>>>>>>> Robert
>>>>>>>
>>>>>>>
>>>>>>> Op Mon, 11 Mar 2013 12:50:38 +0100 schreef Stephen Connolly <
>>>>>>> stephen.alan.connolly@gmail.****com
>>>>>>> <st...@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-unsubscribe@maven.apache.****org<
>>>>>>> dev-unsubscribe@maven.apache.org>
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> ------------------------------****----------------------------**
>>>>>> --**---------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.****org<
>>>>>> dev-unsubscribe@maven.apache.org>
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>> ------------------------------**------------------------------**---------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>> .
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Multi-project releases
Posted by Rahul Thakur <ra...@gmail.com>.
And something like a CI server can make use of this capability as well.
On 3/15/2013 2:20 AM, Robert Scholte wrote:
> At least the maven-help-plugin and probably the maven-site-plugin too.
> There's a small difference between the resolved pom for Maven(core)
> and the way paths are transformed for the maven-release-plugin and
> maven-site-plugin.
>
> here are some examples:
> https://jira.codehaus.org/browse/MSITE-669
> https://jira.codehaus.org/browse/MSITE-672
> https://jira.codehaus.org/browse/MSITE-657
>
> Probably all URLs of distributionManagement are transformed for
> children, but that's not exposed with the help:effective-pom.
>
> Robert
>
> Op Thu, 14 Mar 2013 21:35:15 +0100 schreef Stephen Connolly
> <st...@gmail.com>:
>
>> On Thursday, 14 March 2013, Robert Scholte wrote:
>>
>>> Let's create a new shared component[1] for it: there are more plugins
>>> depending on this intelligence.
>>
>>
>> What other plugins could be concerned with knowing which projects are
>> roots
>> for the release plugin?
>>
>> Or maybe you gave something else in mind?
>>
>>
>>> Looks to me there's no component for this kind of stuff yet.
>>>
>>> Robert
>>>
>>> [1]
>>> http://maven.apache.org/**shared/index.html<http://maven.apache.org/shared/index.html>
>>>
>>>
>>> Op Thu, 14 Mar 2013 10:32:26 +0100 schreef Stephen Connolly <
>>> stephen.alan.connolly@gmail.com>:
>>>
>>> No it makes more sense in the release plugin
>>>>
>>>>
>>>> On 14 March 2013 09:16, Rahul Thakur <ra...@gmail.com>
>>>> wrote:
>>>>
>>>>
>>>>> And perhaps this capability can reside in Maven core? Just a
>>>>> thought....
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 3/12/2013 2:56 AM, Robert Scholte wrote:
>>>>>
>>>>> Hi,
>>>>>>
>>>>>> There are several MSITE/DOXIA and MRELEASE issues related to this
>>>>>> subject.
>>>>>>
>>>>>> For the SCM-section and the site-section of the
>>>>>> distributionManagement
>>>>>> we
>>>>>> need a more intelligent way to resolve this.
>>>>>> Right now this logic is hidden inside the maven-release-plugin and
>>>>>> maven-site-plugin, causing a different result when resolved as
>>>>>> effective-pom, so IMO it is resolved at the wrong place.
>>>>>> They way it should be resolved depends on the type of MavenProject:
>>>>>>
>>>>>> - aggregator (I'm not the parent of my modules)
>>>>>> - multimodule-root (I'm the parent of modules)
>>>>>> - module (I'm a module of my parent)
>>>>>> - standalone (I'm not a module of my parent/I don't have a parent or
>>>>>> modules)
>>>>>>
>>>>>> IMO modules should by default expand their parents path.
>>>>>>
>>>>>> Robert
>>>>>>
>>>>>>
>>>>>> Op Mon, 11 Mar 2013 12:50:38 +0100 schreef Stephen Connolly <
>>>>>> stephen.alan.connolly@gmail.****com
>>>>>> <st...@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-unsubscribe@maven.apache.****org<
>>>>>> dev-unsubscribe@maven.apache.org>
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> ------------------------------****----------------------------**
>>>>> --**---------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.****org<
>>>>> dev-unsubscribe@maven.apache.org>
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>> ------------------------------**------------------------------**---------
>>>
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
> .
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Multi-project releases
Posted by Lennart Jörelid <le...@gmail.com>.
This is an interesting discussion as well as a very relevant direction of
thoughts.
I feel that the maven distribution strategies (mainly within site/release
plugins) are full of
[fairly undocumented] assumptions - the net result of which is a confusing
experience
for the users.
It would seem that the most important task is to devise and describe a
simple and
consistent model for
1. How to derive values for relativization [of URLs or values]. This is
relevant for (at least) release and site plugins, but should be exposed
from a common component to enable simple integration for any plugin
requiring it.
2. How to compose effective values using in multi-project reactors. This
is relevant for releases, such as when combining values from settings.xml
and settings-security.xml are joined with extrapolated values from poms.
*Exactly* what parts go in which files to achieve a properly working
reactor?
3. [A best practise for] how to manage big multi-project reactors in a
maintainable way - without either answering 250 versioning questions from
the release plugin or resorting to a common version for all projects in the
reactor (changed or not).
IMHO these requirements indicate current-state itches which we need to
scratch.
Hopefully with a common component, to minimize deviation in plugin
behaviour.
2013/3/14 Robert Scholte <rf...@apache.org>
> At least the maven-help-plugin and probably the maven-site-plugin too.
> There's a small difference between the resolved pom for Maven(core) and
> the way paths are transformed for the maven-release-plugin and
> maven-site-plugin.
>
> here are some examples:
> https://jira.codehaus.org/**browse/MSITE-669<https://jira.codehaus.org/browse/MSITE-669>
> https://jira.codehaus.org/**browse/MSITE-672<https://jira.codehaus.org/browse/MSITE-672>
> https://jira.codehaus.org/**browse/MSITE-657<https://jira.codehaus.org/browse/MSITE-657>
>
> Probably all URLs of distributionManagement are transformed for children,
> but that's not exposed with the help:effective-pom.
>
> Robert
>
> Op Thu, 14 Mar 2013 21:35:15 +0100 schreef Stephen Connolly <
> stephen.alan.connolly@gmail.**com <st...@gmail.com>>:
>
>
> On Thursday, 14 March 2013, Robert Scholte wrote:
>>
>> Let's create a new shared component[1] for it: there are more plugins
>>> depending on this intelligence.
>>>
>>
>>
>> What other plugins could be concerned with knowing which projects are
>> roots
>> for the release plugin?
>>
>> Or maybe you gave something else in mind?
>>
>>
>> Looks to me there's no component for this kind of stuff yet.
>>>
>>> Robert
>>>
>>> [1] http://maven.apache.org/****shared/index.html<http://maven.apache.org/**shared/index.html>
>>> <http://**maven.apache.org/shared/index.**html<http://maven.apache.org/shared/index.html>
>>> >
>>>
>>>
>>> Op Thu, 14 Mar 2013 10:32:26 +0100 schreef Stephen Connolly <
>>> stephen.alan.connolly@gmail.**com <st...@gmail.com>>:
>>>
>>> No it makes more sense in the release plugin
>>>
>>>>
>>>>
>>>> On 14 March 2013 09:16, Rahul Thakur <ra...@gmail.com>
>>>> wrote:
>>>>
>>>>
>>>> And perhaps this capability can reside in Maven core? Just a
>>>>> thought....
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 3/12/2013 2:56 AM, Robert Scholte wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>>>
>>>>>> There are several MSITE/DOXIA and MRELEASE issues related to this
>>>>>> subject.
>>>>>>
>>>>>> For the SCM-section and the site-section of the distributionManagement
>>>>>> we
>>>>>> need a more intelligent way to resolve this.
>>>>>> Right now this logic is hidden inside the maven-release-plugin and
>>>>>> maven-site-plugin, causing a different result when resolved as
>>>>>> effective-pom, so IMO it is resolved at the wrong place.
>>>>>> They way it should be resolved depends on the type of MavenProject:
>>>>>>
>>>>>> - aggregator (I'm not the parent of my modules)
>>>>>> - multimodule-root (I'm the parent of modules)
>>>>>> - module (I'm a module of my parent)
>>>>>> - standalone (I'm not a module of my parent/I don't have a parent or
>>>>>> modules)
>>>>>>
>>>>>> IMO modules should by default expand their parents path.
>>>>>>
>>>>>> Robert
>>>>>>
>>>>>>
>>>>>> Op Mon, 11 Mar 2013 12:50:38 +0100 schreef Stephen Connolly <
>>>>>> stephen.alan.connolly@gmail.******com <stephen.alan.connolly@gmail.**
>>>>>> com <st...@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-unsubscribe@maven.apache.******org<
>>>>>> dev-unsubscribe@maven.apache.**org <de...@maven.apache.org>
>>>>>> >
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------******--------------------------**--**
>>>>> --**---------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.******org<
>>>>> dev-unsubscribe@maven.apache.**org <de...@maven.apache.org>>
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>> ------------------------------****----------------------------**
>>> --**---------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<de...@maven.apache.org>
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>>
> ------------------------------**------------------------------**---------
>
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<de...@maven.apache.org>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: lj@jguru.se
| URL: www.jguru.se
| Phone
| (skype): jgurueurope
| (intl): +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+
Re: Multi-project releases
Posted by Robert Scholte <rf...@apache.org>.
At least the maven-help-plugin and probably the maven-site-plugin too.
There's a small difference between the resolved pom for Maven(core) and
the way paths are transformed for the maven-release-plugin and
maven-site-plugin.
here are some examples:
https://jira.codehaus.org/browse/MSITE-669
https://jira.codehaus.org/browse/MSITE-672
https://jira.codehaus.org/browse/MSITE-657
Probably all URLs of distributionManagement are transformed for children,
but that's not exposed with the help:effective-pom.
Robert
Op Thu, 14 Mar 2013 21:35:15 +0100 schreef Stephen Connolly
<st...@gmail.com>:
> On Thursday, 14 March 2013, Robert Scholte wrote:
>
>> Let's create a new shared component[1] for it: there are more plugins
>> depending on this intelligence.
>
>
> What other plugins could be concerned with knowing which projects are
> roots
> for the release plugin?
>
> Or maybe you gave something else in mind?
>
>
>> Looks to me there's no component for this kind of stuff yet.
>>
>> Robert
>>
>> [1]
>> http://maven.apache.org/**shared/index.html<http://maven.apache.org/shared/index.html>
>>
>>
>> Op Thu, 14 Mar 2013 10:32:26 +0100 schreef Stephen Connolly <
>> stephen.alan.connolly@gmail.com>:
>>
>> No it makes more sense in the release plugin
>>>
>>>
>>> On 14 March 2013 09:16, Rahul Thakur <ra...@gmail.com>
>>> wrote:
>>>
>>>
>>>> And perhaps this capability can reside in Maven core? Just a
>>>> thought....
>>>>
>>>>
>>>>
>>>>
>>>> On 3/12/2013 2:56 AM, Robert Scholte wrote:
>>>>
>>>> Hi,
>>>>>
>>>>> There are several MSITE/DOXIA and MRELEASE issues related to this
>>>>> subject.
>>>>>
>>>>> For the SCM-section and the site-section of the
>>>>> distributionManagement
>>>>> we
>>>>> need a more intelligent way to resolve this.
>>>>> Right now this logic is hidden inside the maven-release-plugin and
>>>>> maven-site-plugin, causing a different result when resolved as
>>>>> effective-pom, so IMO it is resolved at the wrong place.
>>>>> They way it should be resolved depends on the type of MavenProject:
>>>>>
>>>>> - aggregator (I'm not the parent of my modules)
>>>>> - multimodule-root (I'm the parent of modules)
>>>>> - module (I'm a module of my parent)
>>>>> - standalone (I'm not a module of my parent/I don't have a parent or
>>>>> modules)
>>>>>
>>>>> IMO modules should by default expand their parents path.
>>>>>
>>>>> Robert
>>>>>
>>>>>
>>>>> Op Mon, 11 Mar 2013 12:50:38 +0100 schreef Stephen Connolly <
>>>>> stephen.alan.connolly@gmail.****com
>>>>> <st...@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-unsubscribe@maven.apache.****org<
>>>>> dev-unsubscribe@maven.apache.org>
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>> ------------------------------****----------------------------**
>>>> --**---------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.****org<
>>>> dev-unsubscribe@maven.apache.org>
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Multi-project releases
Posted by Stephen Connolly <st...@gmail.com>.
On Thursday, 14 March 2013, Robert Scholte wrote:
> Let's create a new shared component[1] for it: there are more plugins
> depending on this intelligence.
What other plugins could be concerned with knowing which projects are roots
for the release plugin?
Or maybe you gave something else in mind?
> Looks to me there's no component for this kind of stuff yet.
>
> Robert
>
> [1] http://maven.apache.org/**shared/index.html<http://maven.apache.org/shared/index.html>
>
>
> Op Thu, 14 Mar 2013 10:32:26 +0100 schreef Stephen Connolly <
> stephen.alan.connolly@gmail.com>:
>
> No it makes more sense in the release plugin
>>
>>
>> On 14 March 2013 09:16, Rahul Thakur <ra...@gmail.com> wrote:
>>
>>
>>> And perhaps this capability can reside in Maven core? Just a thought....
>>>
>>>
>>>
>>>
>>> On 3/12/2013 2:56 AM, Robert Scholte wrote:
>>>
>>> Hi,
>>>>
>>>> There are several MSITE/DOXIA and MRELEASE issues related to this
>>>> subject.
>>>>
>>>> For the SCM-section and the site-section of the distributionManagement
>>>> we
>>>> need a more intelligent way to resolve this.
>>>> Right now this logic is hidden inside the maven-release-plugin and
>>>> maven-site-plugin, causing a different result when resolved as
>>>> effective-pom, so IMO it is resolved at the wrong place.
>>>> They way it should be resolved depends on the type of MavenProject:
>>>>
>>>> - aggregator (I'm not the parent of my modules)
>>>> - multimodule-root (I'm the parent of modules)
>>>> - module (I'm a module of my parent)
>>>> - standalone (I'm not a module of my parent/I don't have a parent or
>>>> modules)
>>>>
>>>> IMO modules should by default expand their parents path.
>>>>
>>>> Robert
>>>>
>>>>
>>>> Op Mon, 11 Mar 2013 12:50:38 +0100 schreef Stephen Connolly <
>>>> stephen.alan.connolly@gmail.****com <st...@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-unsubscribe@maven.apache.****org<
>>>> dev-unsubscribe@maven.apache.org>
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>>
>>>>
>>> ------------------------------****----------------------------**
>>> --**---------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.****org<
>>> dev-unsubscribe@maven.apache.org>
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Sent from my phone
Re: Multi-project releases
Posted by Robert Scholte <rf...@apache.org>.
Let's create a new shared component[1] for it: there are more plugins
depending on this intelligence.
Looks to me there's no component for this kind of stuff yet.
Robert
[1] http://maven.apache.org/shared/index.html
Op Thu, 14 Mar 2013 10:32:26 +0100 schreef Stephen Connolly
<st...@gmail.com>:
> No it makes more sense in the release plugin
>
>
> On 14 March 2013 09:16, Rahul Thakur <ra...@gmail.com> wrote:
>
>>
>> And perhaps this capability can reside in Maven core? Just a thought....
>>
>>
>>
>>
>> On 3/12/2013 2:56 AM, Robert Scholte wrote:
>>
>>> Hi,
>>>
>>> There are several MSITE/DOXIA and MRELEASE issues related to this
>>> subject.
>>>
>>> For the SCM-section and the site-section of the distributionManagement
>>> we
>>> need a more intelligent way to resolve this.
>>> Right now this logic is hidden inside the maven-release-plugin and
>>> maven-site-plugin, causing a different result when resolved as
>>> effective-pom, so IMO it is resolved at the wrong place.
>>> They way it should be resolved depends on the type of MavenProject:
>>>
>>> - aggregator (I'm not the parent of my modules)
>>> - multimodule-root (I'm the parent of modules)
>>> - module (I'm a module of my parent)
>>> - standalone (I'm not a module of my parent/I don't have a parent or
>>> modules)
>>>
>>> IMO modules should by default expand their parents path.
>>>
>>> Robert
>>>
>>>
>>> Op Mon, 11 Mar 2013 12:50:38 +0100 schreef Stephen Connolly <
>>> stephen.alan.connolly@gmail.**com <st...@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-unsubscribe@maven.apache.**org<de...@maven.apache.org>
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail:
>> dev-unsubscribe@maven.apache.**org<de...@maven.apache.org>
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Multi-project releases
Posted by Stephen Connolly <st...@gmail.com>.
No it makes more sense in the release plugin
On 14 March 2013 09:16, Rahul Thakur <ra...@gmail.com> wrote:
>
> And perhaps this capability can reside in Maven core? Just a thought....
>
>
>
>
> On 3/12/2013 2:56 AM, Robert Scholte wrote:
>
>> Hi,
>>
>> There are several MSITE/DOXIA and MRELEASE issues related to this subject.
>>
>> For the SCM-section and the site-section of the distributionManagement we
>> need a more intelligent way to resolve this.
>> Right now this logic is hidden inside the maven-release-plugin and
>> maven-site-plugin, causing a different result when resolved as
>> effective-pom, so IMO it is resolved at the wrong place.
>> They way it should be resolved depends on the type of MavenProject:
>>
>> - aggregator (I'm not the parent of my modules)
>> - multimodule-root (I'm the parent of modules)
>> - module (I'm a module of my parent)
>> - standalone (I'm not a module of my parent/I don't have a parent or
>> modules)
>>
>> IMO modules should by default expand their parents path.
>>
>> Robert
>>
>>
>> Op Mon, 11 Mar 2013 12:50:38 +0100 schreef Stephen Connolly <
>> stephen.alan.connolly@gmail.**com <st...@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-unsubscribe@maven.apache.**org<de...@maven.apache.org>
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<de...@maven.apache.org>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Multi-project releases
Posted by Rahul Thakur <ra...@gmail.com>.
And perhaps this capability can reside in Maven core? Just a thought....
On 3/12/2013 2:56 AM, Robert Scholte wrote:
> Hi,
>
> There are several MSITE/DOXIA and MRELEASE issues related to this
> subject.
>
> For the SCM-section and the site-section of the distributionManagement
> we need a more intelligent way to resolve this.
> Right now this logic is hidden inside the maven-release-plugin and
> maven-site-plugin, causing a different result when resolved as
> effective-pom, so IMO it is resolved at the wrong place.
> They way it should be resolved depends on the type of MavenProject:
>
> - aggregator (I'm not the parent of my modules)
> - multimodule-root (I'm the parent of modules)
> - module (I'm a module of my parent)
> - standalone (I'm not a module of my parent/I don't have a parent or
> modules)
>
> IMO modules should by default expand their parents path.
>
> Robert
>
>
> Op Mon, 11 Mar 2013 12:50:38 +0100 schreef Stephen Connolly
> <st...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Multi-project releases
Posted by Robert Scholte <rf...@apache.org>.
Hi,
There are several MSITE/DOXIA and MRELEASE issues related to this subject.
For the SCM-section and the site-section of the distributionManagement we
need a more intelligent way to resolve this.
Right now this logic is hidden inside the maven-release-plugin and
maven-site-plugin, causing a different result when resolved as
effective-pom, so IMO it is resolved at the wrong place.
They way it should be resolved depends on the type of MavenProject:
- aggregator (I'm not the parent of my modules)
- multimodule-root (I'm the parent of modules)
- module (I'm a module of my parent)
- standalone (I'm not a module of my parent/I don't have a parent or
modules)
IMO modules should by default expand their parents path.
Robert
Op Mon, 11 Mar 2013 12:50:38 +0100 schreef Stephen Connolly
<st...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Multi-project releases
Posted by Deng Ching-Mallete <oc...@apache.org>.
Cool, thanks :)
-Deng
On Wed, Mar 13, 2013 at 3:38 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> I thought I had included the link... But it does not seem there now...
> Strange
>
> https://github.com/stephenc/mpr-maven-plugin
>
> On Wednesday, 13 March 2013, Deng Ching-Mallete wrote:
>
> > Hi Stephen,
> >
> > Where can I get/checkout the plugin? We have a project with the same
> > structure so I'd like to try it out.
> >
> > Thanks,
> > Deng
> >
> > On Mon, Mar 11, 2013 at 7:50 PM, Stephen Connolly <
> > stephen.alan.connolly@gmail.com <javascript:;>> wrote:
> >
> > > 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
> > >
> >
> >
> >
> > --
> > Maria Odea "Deng" Ching-Mallete | oching@apache.org <javascript:;> |
> > http://www.linkedin.com/in/oching
> >
>
>
> --
> Sent from my phone
>
--
Maria Odea "Deng" Ching-Mallete | oching@apache.org |
http://www.linkedin.com/in/oching
Re: Multi-project releases
Posted by Stephen Connolly <st...@gmail.com>.
I thought I had included the link... But it does not seem there now...
Strange
https://github.com/stephenc/mpr-maven-plugin
On Wednesday, 13 March 2013, Deng Ching-Mallete wrote:
> Hi Stephen,
>
> Where can I get/checkout the plugin? We have a project with the same
> structure so I'd like to try it out.
>
> Thanks,
> Deng
>
> On Mon, Mar 11, 2013 at 7:50 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com <javascript:;>> wrote:
>
> > 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
> >
>
>
>
> --
> Maria Odea "Deng" Ching-Mallete | oching@apache.org <javascript:;> |
> http://www.linkedin.com/in/oching
>
--
Sent from my phone
Re: Multi-project releases
Posted by Deng Ching-Mallete <oc...@apache.org>.
Hi Stephen,
Where can I get/checkout the plugin? We have a project with the same
structure so I'd like to try it out.
Thanks,
Deng
On Mon, Mar 11, 2013 at 7:50 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> 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
>
--
Maria Odea "Deng" Ching-Mallete | oching@apache.org |
http://www.linkedin.com/in/oching