Maven 2 & 3

Plugins are merged incorrectly

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Blocker Blocker
  • Resolution: Fixed
  • Affects Version/s: 2.0.4
  • Fix Version/s: 2.0.8
  • Component/s: None
  • Labels:
    None
  • Environment:
    Windows XP
  • Complexity:
    Intermediate
  • Number of attachments :
    2

Description

This bug is similar to http://jira.codehaus.org/browse/MANTRUN-57;jsessionid=awtyLFBPEQN6vVmwu4 - the difference being the plugins are not correctly merged.

In the parent's POM, the following was defined:

<build>
  <pluginManagement>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-eclipse-plugin</artifactId>
        <configuration>
          <downloadSources>true</downloadSources>
          <additionalBuildcommands>
            <buildcommand>
              parentBuildCommand
            </buildcommand>
          </additionalBuildcommands>
        </configuration>
      </plugin>
    </plugins>
  </pluginManagement>
</build>

in the child's POM, the following was defined.

<build>
  <pluginManagement>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-eclipse-plugin</artifactId>
        <configuration>
          <additionalBuildcommands>
            <buildcommand>
              childBuildCommand
            </buildcommand>
          </additionalBuildcommands>
        </configuration>
      </plugin>
    </plugins>
  </pluginManagement>
</build>

I expect the effective POM to look like this:

<build>
  <pluginManagement>
    <plugins>
      <plugin>
        <artifactId>maven-eclipse-plugin</artifactId>
        <configuration>
          <additionalBuildcommands>
            <buildcommand>
              parentBuildCommand
            </buildcommand>
            <buildcommand>
              childBuildCommand
            </buildcommand>
          </additionalBuildcommands>
          <downloadSources>true</downloadSources>
        </configuration>
      </plugin>
    </plugins>
  </pluginManagement>
</build>

Outside of the common problem of the <plugin> element being duplicated, here's the issue this bug is trying to address:
In the effective pom, the the <downloadSources> element was correctly merged, however, the <buildCommand> element was not. It seems like the merging only correctly happens down to a given level.

I noticed that http://jira.codehaus.org/browse/MNG-2297;jsessionid=awtyLFBPEQN6vVmwu4 has a patch attached, so this may be fixed in 2.0.5, I just wanted to raise the use case in case that patch did not address this specific problem.

I'm attaching the POMs needed to reproduce the problem and the effective POM for the child.

  1. XML File
    effective-child-pom.xml
    05/Oct/06 9:47 AM
    4 kB
    Allan Shoup

Issue Links

is related to

Improvement - An improvement or enhancement to an existing feature or task. MNG-732 Improve plugin configuration property merge algorithm

  • Critical - Crashes, loss of data, severe memory leak.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
relates to

Bug - A problem which impairs or prevents the functions of the product. MNG-3836 [regression] Inherited collection from plugin configuration is merged with configuration from child whereas child config should completely override collection

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Improvement - An improvement or enhancement to an existing feature or task. MNGSITE-99 POM reference not discuss configuration merging

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • 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
John Casey added a comment -

I'll add a new FAQ entry for this, but essentially it's doing the right thing by default. Since plugin configurations are handled as XML DOM instances by the core, there is an ever-present struggle between when to merge child elements' values with one another (when the child's <source> overrides the parent's, for example), and when you want to append new child elements to the existing list (as in the example above, or any time you have a list of items to aggregate during inheritance).

We've solved this problem using an attribute, 'combine.children'. You simply specify this attribute, with the value of "append" at the parent element where such aggregation should occur, and Maven will switch its merge behavior for that element's children.

NOTE: I fixed this behavior in Maven's trunk; previously, it had been putting the parent POM's sub-elements AFTER those of the child. This is inconsistent with other inheritance functions, so I've reversed the ordering to truly append the child's elements.

So, to recap:

parent:

<configuration>
  <items>
      <item>one</item>
      <item>two</item>
  </items>
</configuration>

child:

<configuration>
  <items combine.children="append">
    <item>three</item>
  </items>
</configuration>

result:

<configuration>
  <items>
    <item>one</item>
    <item>two</item>
    <item>three</item>
  </items>
</configuration>

(If you're using an earlier version of Maven than the present trunk, order will be three, one, two.)

Revision IDs affecting this change are:

plexus-utils: revId 6546
maven-project: revId 513038

I also added a couple unit tests to org.apache.maven.project.ModelUtilsTest in maven-project/src/test/java to cover these cases.

Show
John Casey added a comment - I'll add a new FAQ entry for this, but essentially it's doing the right thing by default. Since plugin configurations are handled as XML DOM instances by the core, there is an ever-present struggle between when to merge child elements' values with one another (when the child's <source> overrides the parent's, for example), and when you want to append new child elements to the existing list (as in the example above, or any time you have a list of items to aggregate during inheritance). We've solved this problem using an attribute, 'combine.children'. You simply specify this attribute, with the value of "append" at the parent element where such aggregation should occur, and Maven will switch its merge behavior for that element's children. NOTE: I fixed this behavior in Maven's trunk; previously, it had been putting the parent POM's sub-elements AFTER those of the child. This is inconsistent with other inheritance functions, so I've reversed the ordering to truly append the child's elements. So, to recap: parent: <configuration> <items> <item> one </item> <item> two </item> </items> </configuration> child: <configuration> <items combine.children= "append" > <item> three </item> </items> </configuration> result: <configuration> <items> <item> one </item> <item> two </item> <item> three </item> </items> </configuration> (If you're using an earlier version of Maven than the present trunk, order will be three, one, two.) Revision IDs affecting this change are: plexus-utils: revId 6546 maven-project: revId 513038 I also added a couple unit tests to org.apache.maven.project.ModelUtilsTest in maven-project/src/test/java to cover these cases.
Hide
Permalink
John Casey added a comment -

See http://docs.codehaus.org/display/MAVENUSER/FAQs-1#FAQs-1-HowdoImergealistofconfigurationitemsinaparentPOMwiththoseinachildPOM%3F

Show
John Casey added a comment - See http://docs.codehaus.org/display/MAVENUSER/FAQs-1#FAQs-1-HowdoImergealistofconfigurationitemsinaparentPOMwiththoseinachildPOM%3F
Hide
Permalink
John Casey added a comment -

sorry, that maven-project revId should be 545315.

Show
John Casey added a comment - sorry, that maven-project revId should be 545315.

People

  • Assignee:
    John Casey
    Reporter:
    Allan Shoup
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: