[regression] Unintended inheritance of parent elements overriden by children

Details

  • Complexity:
    Intermediate

Description

Parent POM snippet:

<ciManagement>
  <system>parent-ci</system>
  <url>http://parent.url/ci</url>
  <notifiers>
    <notifier>
      <type>irc</type>
      <sendOnError>true</sendOnError>
      <sendOnFailure>true</sendOnFailure>
      <sendOnSuccess>false</sendOnSuccess>
      <sendOnWarning>false</sendOnWarning>
      <configuration>
        <address>irc://parent.url/#ci</address>
      </configuration>
    </notifier>
  </notifiers>
</ciManagement>

Child POM snippet:

<ciManagement>
  <system>child-ci</system>
  <url>http://child.url/ci</url>
</ciManagement>

Effective child POM:

<ciManagement>
  <system>child-ci</system>
  <url>http://child.url/ci</url>
  <notifiers>
    <notifier>
      <type>irc</type>
      <sendOnError>true</sendOnError>
      <sendOnFailure>true</sendOnFailure>
      <sendOnSuccess>false</sendOnSuccess>
      <sendOnWarning>false</sendOnWarning>
      <configuration>
        <address>irc://parent.url/#ci</address>
      </configuration>
    </notifier>
  </notifiers>
</ciManagement>

i.e. the notifiers are erroneously inherited although the child has specified its own CI management. Happens to a couple of other elements like <distributionManagement>, too. It appears the all-or-nothing style inheritance present in Maven 2.x for certain elements is not properly emulated on trunk.

Issue Links

is related to

Bug - A problem which impairs or prevents the functions of the product. MNG-2807 ciManagement from parent is not merging with children

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

New Feature - A new feature of the product, which has yet to be developed. MNG-3844 Review inheritance of SCM info

  • Trivial - Cosmetic problem like misspelt words or misaligned text.
  • Open - The issue is open and ready for the assignee to start work on it.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Anders Kr. Andersen added a comment -

Would a work-around be to specify an empty notifiers ?
Otherwise it seems correct behaviour from an overall view, because the properies are merged to the effective pom. And it seems to work fine.

To some extend it is "you" that knows that <notifiers> goes as attributes to a kind of key. As I understand maven, maven knows nothing about this.

Show
Anders Kr. Andersen added a comment - Would a work-around be to specify an empty notifiers ? Otherwise it seems correct behaviour from an overall view, because the properies are merged to the effective pom. And it seems to work fine. To some extend it is "you" that knows that <notifiers> goes as attributes to a kind of key. As I understand maven, maven knows nothing about this.
Hide
Permalink
Benjamin Bentmann added a comment -

Would a work-around be to specify an empty notifiers ?

Nope, has the same result.

The point is that there is no rationale to inherit the notifiers from the parent if the child defines a completely different/unrelated CI system. Maven 2.x "knows" this by stopping inheritance for certain POM subtrees if the child overrides the parent element of such a subtree (c.f DefaultModelInheritanceAssembler).

This issue gets even more annoying for things like dist repos, e.g. a child declaring

<distributionManagement>
  <repository>
    <id>child-distros</id>
    <url>ssh://child.url/distros</url>
  </repository>
</distributionManagement>

still inherits <name>, <uniqueVersion> and <layout> for its repo from the parent despite the URL/ID employed by the child indicating a repository which is completely unrelated to the one specified in the parent.

Show
Benjamin Bentmann added a comment -
Would a work-around be to specify an empty notifiers ?
Nope, has the same result. The point is that there is no rationale to inherit the notifiers from the parent if the child defines a completely different/unrelated CI system. Maven 2.x "knows" this by stopping inheritance for certain POM subtrees if the child overrides the parent element of such a subtree (c.f DefaultModelInheritanceAssembler). This issue gets even more annoying for things like dist repos, e.g. a child declaring 
<distributionManagement>
  <repository>
    <id>child-distros</id>
    <url>ssh://child.url/distros</url>
  </repository>
</distributionManagement>
still inherits <name>, <uniqueVersion> and <layout> for its repo from the parent despite the URL/ID employed by the child indicating a repository which is completely unrelated to the one specified in the parent.
Hide
Permalink
Benjamin Bentmann added a comment -

Fixed in r719930.

Show
Benjamin Bentmann added a comment - Fixed in r719930.
Hide
Permalink
Paul Benedict added a comment -

You guys needs to add a new <inherit> attribute so MNG-2807 can be solved. In essence, we wanted to put our software engineers in the parent POM and inherit them in the children.

Show
Paul Benedict added a comment - You guys needs to add a new <inherit> attribute so MNG-2807 can be solved. In essence, we wanted to put our software engineers in the parent POM and inherit them in the children.
Hide
Permalink
Benjamin Bentmann added a comment -

Paul, this issue was about restoring backward-compat with Maven 2.x (as I am not aware of a spec to break this behavior). What you're after is a new feature or improvement, i.e. another issue.

Show
Benjamin Bentmann added a comment - Paul, this issue was about restoring backward-compat with Maven 2.x (as I am not aware of a spec to break this behavior). What you're after is a new feature or improvement, i.e. another issue.

People

  • Assignee:
    Benjamin Bentmann
    Reporter:
    Benjamin Bentmann
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: