Details
-
Type:
Improvement
-
Status:
Closed
-
Priority:
Critical
-
Resolution: Fixed
-
Affects Version/s: 2.0-alpha-3
-
Fix Version/s: 2.0-beta-1
-
Component/s: Plugins and Lifecycle
-
Labels:None
-
Complexity:Expert
-
Number of attachments :
Description
If the property are the same in the parent and the child project, then the parent property is not inherited. This is fine for simple properties but breaks for complex properties such as lists. Here's an example:
My parent POM:
<build>
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<systemProperties>
<property>
<name>cargo.resin3x.port</name>
<value>8280</value>
</property>
<property>
<name>cargo.resin3x.url</name>
<value>http://www.caucho.com/download/resin-3.0.9.zip</value>
</property>
</systemProperties>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>
My child POM:
<build>
<plugins>
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<systemProperties>
<!-- Default list of containers to run on. If you want to shorten or change the
execution of 'samples', simply specify a shorter list of containers on the
command line or in your settings -->
<property>
<name>cargo.containers</name>
<value>resin3x, orion2x, tomcat5x, jetty4xEmbedded</value>
</property>
<!-- Location where to download and install the containers for the tests -->
<property>
<name>cargo.install.dir</name>
<value>$
/../../target/installs</value>
</property>
</systemProperties>
</configuration>
</plugin>
</plugins>
</build>
It sounds a reasonable expectations that the system properties will get merged.
Issue Links
- depends upon
-
PLXUTILS-22
allow disctinction between merge and override semantics on Xpp3Dom merge method
-
- relates to
-
MNG-2591
Plugins are merged incorrectly
-
Activity
| Field | Original Value | New Value |
|---|---|---|
| Fix Version/s | 2.0-beta-1 [ 11040 ] |
| Priority | Major [ 3 ] | Critical [ 2 ] |
| Complexity | Intermediate | Expert |
| Assignee | John Casey [ jdcasey ] | |
| Remaining Estimate | 1 day [ 86400 ] | |
| Original Estimate | 1 day [ 86400 ] |
| Link | This issue depends upon PLX-150 [ PLX-150 ] |
| Remaining Estimate | 1 day [ 86400 ] | 8 hours [ 28800 ] |
| Original Estimate | 1 day [ 86400 ] | 8 hours [ 28800 ] |
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Original Estimate | 8 hours [ 28800 ] | 3 hours [ 10800 ] |
| Remaining Estimate | 8 hours [ 28800 ] | 3 hours [ 10800 ] |
-
- Time Spent:
- 2 hours
- added a test to verify the new combine.children=append mode works for testExclusions in the compiler plugin...see it0060.
| Time Spent | 2 hours [ 7200 ] | |
| Remaining Estimate | 3 hours [ 10800 ] | 0 minutes [ 0 ] |
| Status | In Progress [ 3 ] | Closed [ 6 ] |
| Resolution | Fixed [ 1 ] |
| Workflow | Maven [ 38653 ] | Maven New [ 46924 ] |
I think I may have traced it to line 278 of ModelUtils in maven-core:
Xpp3Dom childConfiguration = (Xpp3Dom) child.getConfiguration();
Xpp3Dom parentConfiguration = (Xpp3Dom) parent.getConfiguration();
childConfiguration = Xpp3Dom.mergeXpp3Dom( childConfiguration, parentConfiguration );
Which itself leads to the following method from plexus-util/Xpp3Dom.java in Plexus:
private static void mergeIntoXpp3Dom( Xpp3Dom dominant, Xpp3Dom recessive )
{ return; }{
// TODO: how to mergeXpp3Dom lists rather than override?
// TODO: share this as some sort of assembler, implement a walk interface?
if ( recessive == null )
Xpp3Dom[] children = recessive.getChildren();
{ mergeIntoXpp3Dom( childDom, child ); }for ( int i = 0; i < children.length; i++ )
{
Xpp3Dom child = children[i];
Xpp3Dom childDom = dominant.getChild( child.getName() );
if ( childDom != null )
else
{ dominant.addChild( new Xpp3Dom( child ) ); }}
}
Does my use case correspond to the first todo item in the code?