Maven: Lifecycle vs. Phase vs. Plugin vs. Goal

Maven: Lifecycle vs. Phase vs. Plugin vs. Goal

Answering late just to clarify yet another level of granularity missing in this thread: executions (of a goal), which are the smallest units of a Maven build.

Hence, we have build cycles (basically, set of actions for a specific overall goal), which consist of phases (lower granularity, a cycle step), which can invoke a set of configured goals provided by certain plugins. That is, Maven is (also) a plugin executor, each plugin can offer one or more goals. You then (also) decide which goal is attached to which phase, most of the times in the defaul life cycle (without any, that is, the default). But you can actually have yet another level: executions (of the same goal, from the same plugin, or of different goals from different plugins)

A picture I prepared to resume the whole

And indeed this is how Maven shows it (its smallest unit of work) via the unique string in its build log:

plugin-artifactId:plugin-version:plugin-goal (goal-execution-id) @ project-name

For example, we would have:

[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ sample-project ---

Which indeed means (through different levels of granularity):

• During the compile phase (unfortunately only mentioned with mvn -X ... for debugging, under REACTOR BUILD PLAN – Tasks: [...]) →
• I'm invoking the Maven Compiler plugin (specified by artifactId and version) with its compile goal →
• as defined by the execution with the id default-compile.

It's unique because indeed you could have the same goal (of the same plugin) bound to different phases or to the same phase but in different executions (that is, with different configurations). The maven-compiler-plugin, for instance, is also used during the test-compile phase (a different phase) to compile test code (via its testCompile goal) in a different execution (default-testCompile). You could also compile (using the same plugin and goal) some auto-generated code during a different phase as defined by an execution you specified int the POM (and potentially a different configuration).

Default executions are provided out-of-the-box via Maven packaging bindings, that is, by default (and enforcing convention over configuration) Maven already invokes certain goals (of standard plugins) during certain phases. The executions ids of these default invocations are defined according to certain conventions.

This also explains why if you really want to override a default behavior (binding) of a Maven build, you need to specify (override) exactly the same execution id in your POM for the same plugin. You could, for instance, skip compilation simply defining an execution of the maven-compiler-plugin with the same default-compile id but bound to a non existing phase (or an empty one).

To make it short: an execution tells Maven which goal(s) to execute with which configuration within which phase.

Some executions are provided by default (defaul bindings), which explains why the maven minimal pom of just 6 lines can already do a lot (compile, test, package, etc.): executing goals of standard plugins in certain phases: it's convention over configuration. Then, via the pom.xml configuration you can add stuff (executions) to the build or influence the behavior of already configured plugins (in this case no executions section, but just configuration would be enough).

Yes, you could skip build cycles (and their phases) and directly invoke goals (of plugins). Imagine the following:

mvn compiler:compile
mvn compiler:testCompile
mvn surefire:test
mvn jar:jar

(NOTE: you could also invoke inline in only one call)

Here we are compiling app code, test code, execute tests and package: imagine how manual, error-prone, repetitive and time-consuming this would be. Convention over configuration helps us: Maven introduces build life cycles and phases. The default life cycle (with no name, that is, the default), provides a range of phases based on best practices and conventions (the mantra of Maven).
If you want to achieve the same as above, simply run: mvn package and it will automatically compile, test and package your project. How? invoking plugins. That is, phases are meaningful and configurable set of plugins (goals) executions. To make it even more standard, for each phase Maven will firstly invoke any preceeding phase, so that e.g. if you want to test you'll be sure you firstly compile.

p.s. note that when specifying several goals for the same execution, you will still see clearly in the build log two different executions (with the same id) for the two different goals (hence, still unique tuple).

A Maven lifecycle is an (abstract) concept that covers all steps (or better: all the steps the Maven designers decided to support) that are expected to occur in a project's development lifetime. These steps (or stages) are called phases in Maven terminology.

A Maven plugin is a container for/supplier of goals. Code implemented in goals is the real workhorse. (Maven in its core itself is just managing plugins and executing goals). Each of a plugin's goals can be assigned/bound to any of the lifecycle phases.

When invoking mvn <phase> Maven passes all phases (every time) and executes all goals (supplied by plugins) that have been bound to any of the phases prior and up to (and including) the given phase. If there is a phase with no goal bound to it nothing is done. But the phase is passed nevertheless.

I.e. you can't "'insert' additional phases" into one of Maven's built-in lifecycles (clean, default, site). They are already there, always! You could develop your own lifecycle with its own phases but that's far beyond simply using Maven as it is.

Goals can also be executed directly, which you get told when running mvn without any phase or (plugin:)goal [with line breaks and shortened for readability here]:

You must specify a valid lifecycle phase or a goal in the format

<plugin-prefix>:<goal> or

<plugin-group-id>:<plugin-artifact-id>[:<plugin-version>]:<goal>.

Available lifecycle phases are:

...

... see actual output or Maven, Introduction to the Build Lifecycle at References below.

References

• Maven / Introduction to the Build Lifecycle
  

  If you ever wondered how Maven knows what to do without any goal binding in the POM there's a link to default-bindings.xml at the bottom of that page which is located in <Your Maven installation>/lib/maven-core-x.y.z.jar/META-INF/plexus/default-bindings.xml.

  The phases for the built-in lifecycles (clean, default, site) are declared in <Your Maven installation>/lib/maven-core-x.y.z.jar/META-INF/plexus/components.xml under <component-set><components><component><role>org.apache.maven.lifecycle.Lifecycle. See also Lifecycles Reference.

• Maven: The Complete Reference, Chapter 4. The Build Lifecycle

• Maven by Example, 3.5. Core Concepts

And belatedly another diagram

• Lifecycles as yellow rectangles
• Phases of lifecycles as blue rectangles with "callable" phases in darker blue (i.e. the phases with hypenation are not usually called from the command line as they may not be designed to leave the project in a well-defined state).
• Goals as blue lozenges. The association/binding "phase -> goal" shown is the one of the "jar" packaging mode. Every phase can have goals bound to it. This holds of course for each of the lifecycles, although bindings are only show for the "default" lifecycle.
• Plugins as grey clipped rectangles. Plugins provide the Goals that can be bound to the Phases.