Incorrect merge behavior using profile driven plugin configuration

• Complexity:

  Intermediate
• Testcase included:

  yes

Plugin configurations are not merged correctly when contained inside a profile. The attached example demonstrates a failure where the parent contains the configuration, and the child contains the execution. There is no configuration whatsoever in the child. The circumstances required to trigger this are:

• Configuration contains a list of at least 2 complex elements.
• Configuration is inside a profile. This does not happen outside the profile
• The first element in the list contains parameters that the last element does not contain, e.g.:
  <foos>
  <foo>
  <name>first</name>
  </foo>
  <foo />
  <foo />
  </foos>

In this example, there should be a list of three Foo elements. The first should have name="first" and the last two should have name=null. In reality, the second element will have name=null, but the third will have name="first". This behavior holds for all parameters in the first element that do not exist in the last element.

The attached example includes a test plugin with an Element object that demonstrates this behavior.

I have traced down the cause and have some high level ideas about the fix, but I have not coded a patch.

I think there are two bugs that meet under these circumstances to cause the configuration corruption. Certainly there are multiple opportunities to make this pom configuration work as expected.

First, there is no configuration in the child. Why should maven even attempt a merge? I ran maven through the debugger to get a better understanding of the sequence of events. Maven sources the parent pom and the child pom. When the child pom is sourced, it contains the full configuration exactly as it exists in the parent. Then an attempt is made to merge these identical configurations. Maven has the chance to avoid this issue by recognizing that the configuration element does not exist at all in the child and simply inheriting that as is from the parent.

The other bug is not in Maven. It is in Xpp3Dom (http://fisheye.codehaus.org/browse/plexus/plexus-utils/tags/plexus-utils-1.5.1/src/main/java/org/codehaus/plexus/util/xml/Xpp3Dom.java?r=4475#l346). Notice that it iterates over the list of recessive children (from the parent pom) linearly and attempts to do a map-based lookup for the corresponding element in the dominant children (from the child pom). This works fine when you have a composition of several complex types, but it fails when there is a sequence of the identical types. From a bit more abstract perspective, if Xpp3Dom is attempting to merge two identical Xpp3Doms, I would expect the result to be the identity rather than data corruption.

I have not done the research to understand why profile plugins go through this path inside Xpp3Dom but non-profile plugins apparently don't. There may also be other situations which are affected. I have not tried using a pluginManagement element for instance.

Lastly, there is something of a workaround. You can tell Xpp3Dom not to merge by setting the self.combine attribute:
<configuration self.combine="override">
This tells Xpp3Dom to ignore the recessive Xpp3Dom (parent) and just use the dominant (child) which seems odd given that there is no child configuration. However, it will work if you don't have any real merging needs.