maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrei Pozolotin <andrei.pozolo...@gmail.com>
Subject Re: Multi-project releases
Date Sun, 24 Mar 2013 20:35:40 GMT
re: "where these required-to-be-released-artifacts live? "
by looking into <scm> tag, and using still one more convention (to be
decided)
where to look locally before attempting independent remote clone.

-------- Original Message --------
Subject: Re: Multi-project releases
From: Fred Cooke <fred.cooke@gmail.com>
To: Maven Developers List <dev@maven.apache.org>
Date: Sun 24 Mar 2013 03:27:10 PM CDT
>> * can your envisioned plugin automatically recursively release all other
>> dependencies moving upward in the reactor dependency tree?
>>
> Generalising this out a bit, if it's not a multi-module build we're talking
> about, and it's not in SVN (repo per project/module in Git for example),
> how will the proposed plugin even find where these
> required-to-be-released-artifacts live?
>
>
> On Sun, Mar 24, 2013 at 9:23 PM, Andrei Pozolotin <
> andrei.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 <stephen.alan.connolly@gmail.com>
>> To: Andrei Pozolotin <andrei.pozolotin@gmail.com>
>> Cc: Maven Developers List <dev@maven.apache.org>, Robert Scholte
>> <rfscholte@apache.org>
>> Date: Sun 24 Mar 2013 02:32:39 PM CDT
>>>
>>> On Sunday, 24 March 2013, Andrei Pozolotin wrote:
>>>
>>>     Robert, Stephen:
>>>
>>>     1) from my experience "release root /  top-to-bottom / monolithic
>>>     " is a wrong approach.
>>>     please consider instead "start-from-any-module / from-bottom-up /
>>>     incremental" approach, as implemented here:
>>>     https://github.com/barchart/barchart-jenkins-cascade-plugin/wiki
>>>
>>>
>>> You are not getting my plan.
>>>
>>> The plugin I envision will allow picking a release root from the
>>> reactor's set of release roots (suggesting which ones need a release)
>>> and then run release on that one.
>>>
>>> You then iterate until it says all done or you have released what you
>> need
>>> No Big Bang from my PoV
>>>
>>>
>>>
>>>
>>>     2) it would be good to have some wiki page somewhere to flesh out
>>>     all assumptions that currently go into release
>>>     as well as to list the use cases people really need. here is one
>>>     of my use cases:
>>>
>> https://github.com/barchart/barchart-jenkins-tester-ecosystem/blob/master/readme.md
>>>     Andrei
>>>
>>>     -------- Original Message --------
>>>     Subject: Re: Multi-project releases
>>>     From: Robert Scholte <rfscholte@apache.org> <javascript:_e({},
>>>     'cvml', 'rfscholte@apache.org');>
>>>     To: Maven Developers List <dev@maven.apache.org>
>>>     <javascript:_e({}, 'cvml', 'dev@maven.apache.org');>
>>>     Date: Sun 24 Mar 2013 09:42:27 AM CDT
>>>>     Hi Stephen,
>>>>
>>>>     I've just checked your code.
>>>>     Most interesting is our difference of the definition
>>>>     "releaseRoot" (or in my case rootProject, I think we mean the
>>>>     same thing with it).
>>>>     If I'm correct you base it on the existence of the <scm>-section
>>>>     and if it has ever been released (assuming a specific scm comment).
>>>>     MRELEASE-814[1] is probably a good example for which this
>>>>     strategy won't work.
>>>>     I try to base it on the parent/module relationship.
>>>>
>>>>     Although this looks close related to MRELEASE-516[2] it is
>>>>     actually a complete other issue.
>>>>     The problem I have with MRELEASE-516 is that it's not the
>>>>     "plug-and-play" behavior you'd like to have,
>>>>     which means that the developer is responsible for checking out
>>>>     separate projects in the right structure.
>>>>
>>>>     Robert
>>>>
>>>>     [1] https://jira.codehaus.org/browse/MRELEASE-814
>>>>     [2] https://jira.codehaus.org/browse/MRELEASE-516
>>>>
>>>>
>>>>     Op Mon, 11 Mar 2013 12:50:38 +0100 schreef Stephen Connolly
>>>>     <stephen.alan.connolly@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
>>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message