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 <[email protected]>:

Done... we are now down to 17 issues still in scope for 3.2.0


On 17 January 2014 11:38, Stephen Connolly
<[email protected]>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 <
[email protected]> 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 No way to avoid adding
   artifactId to site urls


I would like some discussion on this one before making a call one way or
the other

   - http://jira.codehaus.org/browse/MNG-4173 Remove automatic version
   resolution for POM plugins






On 13 January 2014 18:02, Stephen Connolly <
[email protected]> wrote:

wiki updated ;-)


On 13 January 2014 17:56, Benson Margulies <[email protected]>wrote:

Done.

On Mon, Jan 13, 2014 at 12:53 PM, Benson Margulies
<[email protected]> wrote:
> On Mon, Jan 13, 2014 at 11:59 AM, Stephen Connolly
> <[email protected]> wrote:
>> On 13 January 2014 16:13, Benson Margulies <[email protected]>
wrote:
>>>
>>> Why isn't this copied to the dev list?
>>
>>
>> It was, check the headers
>
> I see. GMail has learned a new prank, which is to skip 'dev' in the
> brief listing of who is on the email.
>
>>
>>>
>>>
>>>
>>> I don't see why  http://jira.codehaus.org/browse/MNG-3879 is even
>>> remotely under consideration.
>>
>>
>> I moved MNG-3879 to 4.0 backlog.
>>
>> Your action was to split out the second issue... should really live
in the
>> dependency plugin and depend on MNG-3879
>
> OK, seems less that wildly important, but I'll do it.
>
>>
>>> The second part is a goal that I would propose to call
'dependency-map'.
>>> This would produce a formatted map of the dependency tree –
enriched, of
>>> course, by the comments in the first part.
>>
>>
>>>
>>> It is a proposal, to start with, to add
>>> an element to the POM:
>>>
>>> <dependency>
>>>             <explanation>some text </explanation>
>>>             ...
>>> </dependency>
>>>
>>> which would make it a job for 4.0. It was never my intention to
>>> propose to capture <!-- --> XML comments, that's evil in my view.
>>>
>>> So far, the feedback I've received is that the stuff I've written
>>> about POM evolution is crap. Fine, it's crap.
>>
>>
>> I don't think necessarily so... once 3.2.0 is out we will be looking
at
>> model version 5.0.0 and pom evolution is on the cards. I like the
idea of
>> dedicated documentation nodes in the pom as otherwise it can be
harder to
>> maintain comments etc, when people use formatting tools etc. The
great thing
>> with a descriptive text node is that everyone except tooling can
ignore it
>>
>>>
>>> So JIRAs like this
>>> should just be closed down when they have my name on them.
>>>
>>> On Mon, Jan 13, 2014 at 8:24 AM, Stephen Connolly
>>> <[email protected]> wrote:
>>> > I have added a wiki page summary of this discussion:
>>> >
>>> >
https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.2.0+Bug+Scrub
>>> >
>>> > Reminder, I pegged some action items against Benson, Olivier,
Kristian &
>>> > Jason... See the action required section... mostly just status
updates.
>>> >
>>> >
>>> > On 7 January 2014 22:03, Stephen Connolly
>>> > <[email protected]>
>>> > wrote:
>>> >>
>>> >> I like "Nike" style issues (just commit it)
>>> >>
>>> >>
>>> >> On Tuesday, 7 January 2014, Michael Osipov wrote:
>>> >>>
>>> >>> Am 2014-01-07 22:38, schrieb Stephen Connolly:
>>> >>>>
>>> >>>> Add it if you promise to implement it, otherwise put it
against 3.2.x
>>> >>>> for
>>> >>>> the patch releases.
>>> >>>
>>> >>>
>>> >>> That is not going to be a problem because I have a patch and can
>>> >>> commit
>>> >>> right away.
>>> >>>
>>> >>>> On Tuesday, 7 January 2014, Michael Osipov wrote:
>>> >>>>
>>> >>>>> Am 2014-01-07 16:25, schrieb Stephen Connolly:
>>> >>>>>
>>> >>>>>> OK we are now at 38 open issues.... anyone else feel like
scrubbing
>>> >>>>>> some
>>> >>>>>> more?
>>> >>>>>>
>>> >>>>>
>>> >>>>> I'd like to add another issue to 3.2:
>>> >>>>> https://jira.codehaus.org/browse/MNG-5176 Print build times
in an
>>> >>>>> ISO
>>> >>>>> 8601-style manner
>>> >>>>>
>>> >>>>> It adds readability to the time output.
>>> >>>>>
>>> >>>>> Mike
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
---------------------------------------------------------------------
>>> >>>>> To unsubscribe, e-mail: [email protected]
>>> >>>>> For additional commands, e-mail: [email protected]
>>> >>>>>
>>> >>>>>
>>> >>>>
>>> >>>
>>> >>>
>>> >>>
---------------------------------------------------------------------
>>> >>> To unsubscribe, e-mail: [email protected]
>>> >>> For additional commands, e-mail: [email protected]
>>> >>>
>>> >>
>>> >>
>>> >> --
>>> >> Sent from my phone
>>> >
>>> >
>>
>>





---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to