*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 <[email protected]>
To: Maven Developers List <[email protected]>, Andrei Pozolotin
<[email protected]>
Cc: "Stephen Connolly" <[email protected]>
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
> <[email protected]>:
>
>> 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 <[email protected]>
>> To: Maven Developers List <[email protected]>
>> 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
>>> <[email protected]>:
>>>
>>>> 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: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>>
>
