maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benjamin Bentmann (JIRA)" <>
Subject [jira] Closed: (MNG-4022) Incorrect merge behavior using profile driven plugin configuration
Date Tue, 06 Apr 2010 21:10:23 GMT


Benjamin Bentmann closed MNG-4022.

    Resolution: Fixed
      Assignee: Benjamin Bentmann

Fixed in [r931329|].

> Incorrect merge behavior using profile driven plugin configuration
> ------------------------------------------------------------------
>                 Key: MNG-4022
>                 URL:
>             Project: Maven 2 & 3
>          Issue Type: Bug
>          Components: Profiles
>    Affects Versions: 2.0.9
>         Environment: Fedora 10 x86_64, not a factor
>            Reporter: John McNair
>            Assignee: Benjamin Bentmann
>             Fix For: 3.0-beta-1
>         Attachments:
> 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,
> <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 (
 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:
For more information on JIRA, see:


View raw message