One best practice with the Maven build system is to take configuration that’s common to many projects and put it into a parent pom.xml.
Unfortunately, parent pom inheritance has some limits. One of them is that profiles aren’t inherited.
You may be forgiven for thinking that profiles ARE inherited. Not only does it seem like a logical (some would say necessary) feature of Maven, you might have seen it working… or so you thought. See, profiles in parent poms can be triggered by the building of a child. When activated, they are applied directly to the parent pom, prior to that parent being used for inheritance into the child. So the effects of an active profile in a parent pom may be felt by the child.
Sometimes this indirect inheritance works well. Sometimes, it’s just crack-addled.
When It Works…
Here’s an example where it works well. Say you have a parent pom with a ‘prod’ profile whose job is to insert some properties into the build. On a production system, Maven will activate that profile and the parent pom will contain the properties. Since properties are inherited from parents, your child pom will get them. The end effect is just like the profile was inherited, but in fact the profile was NOT inherited.
… and When It Doesn’t
Here’s an example where it doesn’t. Say your parent pom has a ‘prod’ profile that adds a module for publishing your app to a webserver. On your production system, Maven will activate that profile and the parent pom will contain the module. However, that module will try to publish the parent to the webserver, not your child project.
If you simply insist on trying to “inherit” plugins via a profile, you’d have to:
- Set up the profile in the parent pom, but instead of defining the module in a <plugin> section, define it in a <pluginManagement> section. The pluginManagement is explicitly for declaring plugins that aren’t used in the parent but need to be propagated to the child.
- Set up the profile again in the child pom (yes, copy and paste). Within the profile, REdeclare the plugin (in a <plugin> section not <pluginManagement>), but without all the configuration. This will activate the plugin defined in the parent.
Yes, it sucks that you have to double-declare things. I try to find other solutions if at all possible.