http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
https://maven.apache.org/guides/mini/guide-configuring-plugins.html#
A lifecycle consists of different phases, e.g. compile
, test
, integration-test
, deploy
etc. Each phase is executed via several plug-ins. A plug-in may have many goals of which each is bound to a default (or custom) phase.
Different goals of the same plug-in can be bound to different phases, e.g.
<execution>
<id>flatten</id>
<phase>process-resources</phase>
<goals>
<goal>flatten</goal>
</goals>
</execution>
<execution>
<id>flatten.clean</id>
<phase>clean</phase>
<goals>
<goal>clean</goal>
</goals>
</execution>
A plug-in goal may not be bound to any phase in which case the goal can be executed directly.
A plug-in can be configured via <configuration>
element under <plugin>
. This configuration applies to the plugin globally, i.e. to every goal of the plugin. Moreover, a certain goal can also be configured individually. This is done via executions. Configuration is applied to the execution name where goal is bound to. Note that execution name matters. We need to find out default execution name of the goal that is being configured.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-deploy-plugin</artifactId>
<executions>
<execution>
<id>deploy-file</id>
<phase>deploy</phase>
<goals>
<goal>deploy-file</goal>
</goals>
<configuration>
<file>...</file>
<version>...</version>
<url>...</url>
<pomFile>...</pomFile>
</configuration>
</execution>
<execution>
<id>default-deploy</id>
<goals>
<goal>deploy</goal>
</goals>
<configuration>
<skip>true</skip>
</configuration>
</execution>
</executions>
</plugin>
The above configuration results to the following execution
...
[INFO] --- maven-deploy-plugin:2.7:deploy (default-deploy) @ reference-manager-app ---
[INFO] Skipping artifact deployment
[INFO] --- maven-deploy-plugin:2.7:deploy-file (deploy-file) @ reference-manager-app ---
Downloading from remote-repository:
...
<phases>
<phase>validate</phase>
<phase>initialize</phase>
<phase>generate-sources</phase>
<phase>process-sources</phase>
<phase>generate-resources</phase>
<phase>process-resources</phase>
<phase>compile</phase>
<phase>process-classes</phase>
<phase>generate-test-sources</phase>
<phase>process-test-sources</phase>
<phase>generate-test-resources</phase>
<phase>process-test-resources</phase>
<phase>test-compile</phase>
<phase>process-test-classes</phase>
<phase>test</phase>
<phase>prepare-package</phase>
<phase>package</phase>
<phase>pre-integration-test</phase>
<phase>integration-test</phase>
<phase>post-integration-test</phase>
<phase>verify</phase>
<phase>install</phase>
<phase>deploy</phase>
</phases>
If a plug-in is defined under the plugins
section in parent POM, all children automatically inherit and invoke the plug-in.
However, if a plug-in is defined under pluginManagement
in parent POM, it's not automatically inherited. The intention is that pluginManagement
is to declare default configurations for its children to inherit. If a child POM wants to use that plugin, it needs to define it with the <plugin>
element and it gets the configuration from the parent. If it's not defined, then plugin is ignored in the children. In general, <plugin>
element makes the actual invocation/use of the plugin.