[ http://jira.codehaus.org/browse/MNG-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jason van Zyl updated MNG-4022: ------------------------------- Fix Version/s: (was: 2.2.x) 3.0-alpha-7 > Incorrect merge behavior using profile driven plugin configuration > ------------------------------------------------------------------ > > Key: MNG-4022 > URL: http://jira.codehaus.org/browse/MNG-4022 > 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 > Fix For: 3.0-alpha-7 > > 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