- 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/
andn
/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
-
-
Save lppedd/13dc421279dd7ba998bc30dfcd6c6579 to your computer and use it in GitHub Desktop.
mvn, how combine.children="append" combine.self="override" (default is "merge" for both) work in multimodule projects
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment