If you want to have a profile which should be applied to sub-modules (and only some of them), defined in a centralized way in their parent project (pom) and yet not apply the profile to the parent itself, here is a proposed approach:
Define the profile in the parent pom, sample one:
<profiles>
<profile>
<id>sample-profile</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.5</version>
<executions>
<execution>
<id>print-hello</id>
<phase>${phase.prop}</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<target>
<echo message="hello there!" />
</target>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
Note what we are doing:
- the plugin
phase
element is parametrized, so the binding of the plugin to a build phase will also be parametrized
- We can now decide via property to which phase attach this plugin execution
- We can now decide via property to attach this plugin execution to no phase (or empty phase)
So, in the same parent pom, let's define the property:
<properties>
<phase.prop>none</phase.prop>
</properties>
As such, the build running on the parent pom will attach the plugin execution to no phase (none
is not a keyword or known-value, just a de-fact standard used for a non existing phase, you could leave it empty or put it any value you like, it would have the same effect) and hence skip it. It will also be skipped by default in all the declared modules. The profile will still be active in every module, but would be harmless since it would not execute any plugin by default.
Then, in modules where you want the plugin executions to be active you could re-define only the concerned property and the required phase:
<properties>
<phase.prop>package</phase.prop>
</properties>
When then activating the profile from the main build (the parent)
mvn clean install -Psample-profile
The parent will apply it to all modules, but the effective profile execution will only occur where the phase.prop
value has a maven-meaningful value.
If you need to have different phases for different plugin executions, then you could define more than one property and apply the same pattern.
If you don't have a plugin execution but rather a global plugin configuration for a plugin already executed by Maven (as part of its packaging and default build), you could then re-define its execution overriding the default execution id.
Note that we could have done the same using the skip
configuration element, but:
- not all plugins provide the
skip
configuration entry
- using the
phase
element is not related to any configuration and can be reused for executions attached to the same phase