Op Sun, 19 Jan 2014 09:59:25 +0100 schreef Stephen Connolly
<stephen.alan.conno...@gmail.com>:
On Saturday, 18 January 2014, Jason van Zyl <ja...@takari.io> wrote:
I don't think you want the CI element propagating. In the case of a
multi-module project you're likely only to have one CI job for that set
of
projects.
But in the multi module case, the CI for the multi-module *is the exact
same* as for the children.
It's not that one-on-one.
A CI-plan/job checks out a specific scm-root and executes that. All
children are just part of that execution.
So if you follow the link from a module and it would inherit the value,
you'll end up on a different folder. So I agree with Jason here.
Maybe the real question is: when is this element used? If it is a
project-info-report, we can improve it by saying something like: "Is part
of ...".
I'm not aware of other usages of this element.
Robert
I don't think it makes sense to inherit this. In our lineage for all
the
Maven projects it probably would work, or be useful, to inherit
anything.
We need to define the jobs in each project and I wouldn't want to try to
guess inheritance rules for various CI systems. We'll end up with the
same
nonsense trying to inherent SCM path elements.
I wouldn't do the path additions at all.
So I would say close MNG-2807 as won't fix.
I have no strong view either way... What is the opinion of others?
Mailing lists is debatable. I don't really have a strong opinion.
The counter-argument against mailing list is an uber-parent pom that has
its own mailing list for discussing what goes in that uber-parent...
I think modelVersion 5.0.0 should have an <inherit> tag for these things
so
that parents can differentiate correctly...
Which now that I think about it makes me suggest push back to
modelVersion
bump?
On Jan 17, 2014, at 11:04 AM, Robert Scholte <rfscho...@apache.org>
wrote:
> Hi,
>
> Regarding MNG-3124 (Inherit mailing lists from parent POM) and
MNG-2807
(ciManagement from parent is not merging with children)
> See MavenModelMerger[1]. This class extends the ModelMerger[2], a
class
which is a handcrafted class as if it was generated by modello.
> It seems like Benjamin wanted wanted to change the default behavior of
the ModelMerger for some good reason.
> So it seems intended, maybe we need to dig a bit deeper to find out
the
actual reason.
>
> Robert
>
> [1]
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-model-builder/src/main/java/org/apache/maven/model/merge/MavenModelMerger.java;hb=HEAD
> [2]
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-model/src/main/java/org/apache/maven/model/merge/ModelMerger.java;hb=HEAD
>
>
> Op Fri, 17 Jan 2014 12:41:40 +0100 schreef Stephen Connolly <
stephen.alan.conno...@gmail.com>:
>
>> Done... we are now down to 17 issues still in scope for 3.2.0
>>
>>
>> On 17 January 2014 11:38, Stephen Connolly
>> <stephen.alan.conno...@gmail.com>wrote:
>>
>>> OK, 4 days and no objections... these are being pushed out of scope
for
>>> 3.2.0
>>>
>>>
>>> On 13 January 2014 18:07, Stephen Connolly <
>>> stephen.alan.conno...@gmail.com> wrote:
>>>
>>>> The following issues I proposed to move to 4.x. I have not heard
anything
>>>> to the contrary... shall I pull the trigger on these?
>>>>
>>>> - http://jira.codehaus.org/browse/MNG-4622 Throw Validation Error
if
>>>> pom contains a dependency with two different versions.
>>>> - http://jira.codehaus.org/browse/MNG-683 Lifecycle mappings
should
>>>> specify phase bindings in terms of general functionality type
>>>>
>>>>
>>>> - http://jira.codehaus.org/browse/MNG-841 Support customization
of
>>>> default excludes
>>>>
>>>>
>>>> - http://jira.codehaus.org/browse/MNG-193 symmetry for outputs
of a
>>>> plugin
>>>>
>>>>
>>>> - http://jira.codehaus.org/browse/MNG-3695 Allow dependencies'
scopes
>>>> to be managed without explicit versions
>>>> - http://jira.codehaus.org/browse/MNG-3825 Dependencies with
>>>> classifier should not always require a version.
>>>> - http://jira.codehaus.org/browse/MNG-3321 Skip plugin and/or
>>>> execution
>>>> -
>>>> - http://jira.codehaus.org/browse/MNG-1569 Make build process
info
>>>> read-only to mojos, and provide mechanism for explicit out-params
for mojos
>>>> to declare
>>>>
>>>>
>>>> - http://jira.codehaus.org/browse/MNG-1867 deprecate system
scope,
>>>> analyse other use cases
>>>> - <http://jira.codehaus.org/browse/MNG-4508>Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
