* the combine.* attributes belong to the configuration elements child elements but in the child not the parent pom
* let's say we have a prepared configuration for some plugin build::pluginmanagement in the parent pom and the combine rules are applied
 to some more specific configuration of this plugin inside a profile in the child pom then we **need to specify this profile** in the mvn call
 to convince us: `mvn -Ptheprofile -f thesubmodule/pom.xml help:effective-pom| less` (use the search functionality `/` and `n`/`SHIFT-n` to
 navigate to the right occurrences)
* IMHO the `combine.children=append` rule doesn't really make sense for configuration elements that have children of heterogeneous names,
 i. e. `systemPropertyVariables`, here the effect in case some entry already existed in the default configuration another one of the same
 name would be added i. e. you had `<someEntrySays>this</someEntrySays>` (from parent pom) and
 `[...]combine...="append"[...]<someEntrySays>that</someEntrySays>` (from child pom) in the effective pom then - tested it with maven 3.3.1.
 I would stick to the default setting `[...]combine...="merge"[...]` in those cases - leading to only `<someEntrySays>that</someEntrySays>`
 (from child pom) in the effective pom
* don't be tricked when looking at the elements effective setting in the other profiles: It is all due **to the profile active** at the
 time
* In case you still use the `[...]combine...="append"[...]` with heterogeneous elements be reminded that append means added to the end of the
 existing list which in turn means in combination with the topdown rule of maven ("the last wins") that in case of duplicates the element
 added later is the active one