Incorrect merge behavior using profile driven plugin configuration
------------------------------------------------------------------
Key: MNG-4022
URL: http://jira.codehaus.org/browse/MNG-4022
Project: Maven 2
Issue Type: Bug
Components: Profiles
Affects Versions: 2.0.9
Environment: Fedora 10 x86_64, not a factor
Reporter: John McNair
Attachments: maven-plugin-merge.zip
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
