I have a multi parent project (child with grandparent pom). The grandparent pom specifies a variable (happens to be the version) that gets overridden by the child. How can I get that value to either be static or reference the "top" parent?
realizing this may need clarification
Let's say that our grandparent pom is
<groupId>group</groupId>
<artifactId>grandparent-pom</artifactId>
<version>1.3-SNAPSHOT</version>
<properties>
<grandparent-pom-version>${version}</grandparent-pom-version>
</properties>
This puts the un-substituted variable in the installed pom file, so everything that inherits from it is substituting the local value. One alternative is to look back at the parent ${parent.version}, but this gets lost once we hit the third generation.
Related
We have 6 child modules, and all of them have same values for & . But slight addition in jvmArguments for few modules.
I want to extract this out into a common place either parent pom or a property file.
what i have done is
<mymodule-jvmArguments>long list of props</mymodule-jvmArguments>
in parent pom and use this property in child modules.
so whereever there is additional propeties, it would be like
<jvmArguments>
additional properties
${mymodule-jvmArguments}
</jvmArguments>
Is this something advisable? Please suggest if there is a better means to handle shared properties. Thanks in advance
child pom sample properties
<jvmArguments>
-DmyAppp1.host=${local.base.url}:${myAppp1.port}
-DmyAppp2.host=${local.base.url}:${myAppp2.port}
-DSENSITIVE_CONFIG_PATH1=${project.parent.parent.basedir}/foo1/bar1
-DSENSITIVE_CONFIG_PATH1=${project.parent.parent.basedir}/foo1/bar1
-DDSENSITIVE_CONFIG_PATH3=${project.parent.parent.basedir}/foo3/bar3
-DDSENSITIVE_CONFIG_PATH4=${project.parent.parent.basedir}/foo4/bar4
-DCOMMON_SENSITIVE_PATH=${project.parent.parent.basedir}/foo/common
</jvmArguments>
When inheriting from a parent POM, is there a list of which element types will be merged (i.e. the actual value in the child is the union of the parent values and the child values) vs which will be clobbered (i.e. if the child specifies a value, it overrides the parent value)?
You can find the list of values inherited from parent pom here .
About that clobbering AFAIK for the leaf nodes if the item has no id then child's definition will override the parent value as in the dependency declaration and parameter values.
If there is an id you should use that id to override the value.
For the outer nodes like "dependency","plugins","repositories" the default behaviour is merge.
If for example there is different plugin definitions in both parent and child those will be merge. If there is a definition for the same plugin then the value in the child will override the parent's one.
If my pom is a child a hierarchy of other poms, is there a way to show exactly which parent pom contains the definition of a plugin?
Short answer is most probably: No.
According to the way Maven builds its model before executing a certain build, the Maven Builder Model:
In phase 1 the hierarchy of poms is resolved
In phase 2 model normalization and plugins configurations are further resolved
But only at the end of phase 2 the effective model validation is performed, which is done on the final effective pom.xml file, as a result of merges, overriding, profiling, injections (of properties) and so on.
To have a look at the full pom, the effective-pom goal of the maven-help-plugin is definitely the right tool. It will show (or write to a given file) the final effective pom a build is gonna use.
The full definition of a plugin (its executions, its global configuration and so on) can only be created once we have the effective pom, because:
the pluginManagement section in any point in the hierarchy can influence a certain plugin
The plugin section in any point in the hierarchy can also influnce it
profiles declared in any point in the hierarchy can also influence it
properties, if used as placeholders, can also play an important role
Having a look at the official Maven POM reference, we can see many entry point to influence a certain plugin definition, which will only be effective to our build once merged through the whole pom hierarchy. A definition per se would not help much since it can then be overriden/influenced further on on the hierarchy chain.
Think about the inherited element of a plugin:
true or false, whether or not this plugin configuration should apply to POMs which inherit from this one. Default value is true.
Or merging of plugin configuration sections:
The default behavior is to merge the content of the configuration element according to element name. If the child POM has a particular element, that value becomes the effective value. if the child POM does not have an element, but the parent does, the parent value becomes the effective value.
You can control how child POMs inherit configuration from parent POMs by adding attributes to the children of the configuration element. The attributes are combine.children and combine.self. Use these attributes in a child POM to control how Maven combines plugin configuration from the parent with the explicit configuration in the child.
Or further down per execution of a plugin:
inherited: Like the inherited element above, setting this false will supress Maven from passing this execution onto its children. This element is only meaningful to parent POMs.
The overall management can then be influenced by pluginManagement:
Plugin Management contains plugin elements in much the same way, except that rather than configuring plugin information for this particular project build, it is intended to configure project builds that inherit from this one. However, this only configures plugins that are actually referenced within the plugins element in the children. The children have every right to override pluginManagement definitions.
As such, the plugin definition at a certain point of the pom hierarchy may not be meaningful to the final effective build.
I am trying to find an authoritative list of which elements get inherited from a parent POM. Based on this page
When you inherit a POM, you can choose to live with the inherited POM information or to selectively override it. The following is a list of items a Maven POM inherits from its parent POM:
identifiers (at least one of groupId or artifactId must be overridden.)
dependencies
developers and contributors
plugin lists
reports lists
plugin executions (executions with matching ids are merged)
plugin configuration
But when I see the effective POM in one of my projects I see it also inherits inceptionYear, description (which is a problem, this should be a description of the POM that contains it, not of its children. What's the point of all children having a description like "The root of all POMs")
So is there an actual list or does it just inherit everything from the parent pom? i use some of these properties in the artifact's manifest so I want to add meaningful values
The child pom inherits everything from the parent pom. If you need to set meaningful values in the child pom then you will need to override the values in the parent pom.
From the Docs:
When a project specifies a parent project, Maven uses that parent POM
as a starting point before it reads the current project’s POM. It
inherits everything, including the groupId and version number.
Most elements from the parent POM are inherited by its children. Two elements that aren't inherited are artifactId & name. (Also, any plugins which explicitly set <inherited>false)
I have a maven multimodule project and I was hoping i could use profiles to customize the configuration of a plugin for two cases based on a POM property but it turns out profiles can only be activated by external properties and not by POM properties so now I am looking for another way to have a different project configuration and i wanted to get some ideas. Here is my setup
I have a 3-levels tree: A root parent POM X with many many submodules A, B, C, ... and each of these modules has 2 submodules 1 and 2 (so A1, A2, B1, B2, etc.)
what i need to do is customize the configuration of a leaf module for all modules of type 1 and another for all modules of type 2. I am trying to avoid making all 1's share a common parent and all 2's another (different) common parent since 1 and 2 already share some data from their respective parent (A or B of example). If there is no other way, I will push down all the common data from A to A1 and A2 (not ideal, DRY principle)and make all 1's inherit from a common 1 parent, but i'm trying to avoid this. Like i said, something i tried was to set a property in the leaves of the tree with a property specifying if it was a 1 or a 2 and then putting the two different profiles in the grandparent POM X and activating the profile based on the property. This didn't work.
Any other suggestions?
I believe you can accomplish your goal with <pluginManagement>
For example, in your parent POM, you have something like this:
<pluginManagement>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.5</version>
<configuration>
<systemPropertyVariables>
<vendor.license.file>../licenses/vendor.lic</vendor.license.file>
</systemPropertyVariables>
</configuration>
</plugin>
</pluginManagement>
Which defines Surefire version 2.5 in for the POM's child modules. Note that you can actually put more than just the version in the plugin configuration, such as a configuration that child projects inherit (and override). See Maven POM Reference - Plugin Management