maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Cooke <fred.co...@gmail.com>
Subject Re: Multi-project releases
Date Sun, 24 Mar 2013 21:03:33 GMT
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 <fred.cooke@gmail.com> <fred.cooke@gmail.com>
> To: Maven Developers List <dev@maven.apache.org> <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> <stephen.alan.connolly@gmail.com>
> To: Andrei Pozolotin <andrei.pozolotin@gmail.com> <andrei.pozolotin@gmail.com>
> Cc: Maven Developers List <dev@maven.apache.org> <dev@maven.apache.org>,
Robert Scholte<rfscholte@apache.org> <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> <rfscholte@apache.org> <javascript:_e({},
>     'cvml', 'rfscholte@apache.org');>
>     To: Maven Developers List <dev@maven.apache.org> <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> <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