[
http://jira.codehaus.org/browse/MNG-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-4022:
------------------------------
Fix Version/s: 2.1.x
> 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
> Fix For: 2.1.x
>
> 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
