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

Relatively new developer here, even though I've been using it for a little while, I'm hoping to solidify my Maven fundamentals. Part of my problem is that I have no experience with Ant, which seems to be from where many explanations stem. I've been reading and watching tutorials, and I keep hearing the same terms:

• Lifecycle
• Phase
• Plugin
• Goal

From what I've learned, it seems that lifecycle is the broadest of the bunch, and is composed of (or completed by) phases, plugins, and/or goals.

Question: Could you provide any info on how these terms are related and the most common examples?

The more explicit and basic, the better!

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. 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

> 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).

Credit to Sandeep Jindal and Premraj (from here https://stackoverflow.com/questions/16205778/what-are-maven-goals-and-phases-and-what-is-their-difference). Their explanation help me to understand.

I created some full code examples & some simple explanations here https://www.surasint.com/maven-life-cycle-phase-and-goal-easy-explained/ . I think it may help others to understand and can try something directly.

In short from the link, You should not try to understand all three at once, first you should understand the relationship in these groups:

• Life Cycle vs Phase
• Plugin vs Goal

1. Life Cycle vs Phase

Life Cycle is a collection of phase in sequence, see here Life Cycle References. When you call a phase, it will also call all phases before it.

For example, the clean life cycle has 3 phases (pre-clean, clean, post-clean).

mvn clean

It will call pre-clean and clean.

2. Plugin vs Goal

Goal is like an action in Plugin. So if plugin is a class, goal is a method.

you can call a goal like this:

mvn clean:clean

This means "call the clean goal, in the clean plugin" (Nothing relates to the clean phase here. Don't let the word"clean" confusing you, they are not the same! See full explanation in my link above)

3. Now the relation between Phase & Goal:

Phase can (pre)links to Goal(s).For example, normally, the clean phase links to the clean goal. So, when you call this command:

mvn clean

It will call the pre-clean phase and the clean phase which links to the clean:clean goal.

It is almost the same as:

mvn pre-clean clean:clean

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.

Sourced from this really good tutorial:

Lifecycles, Lifecycle Phases, Plugins and Plugin Goals are the core of Maven.

• The Maven command mvn only accepts Lifecycle Phases or Plugin Goals as arguments.
• Maven comes with three lifecycles: default, clean and site.
• Each lifecycle is made up of lifecycle phases and in all, there are 28 phases – 21 in default (validate, ..., compile, ..., package, ..., install, deploy), 3 in clean (pre-clean, clean, post-clean) and 4 in site (pre-site, site, post-site, site-deploy).
• When a lifecycle phase is invoked using the mvn command, all preceding phases are executed sequentially one after another.
• lifecycle phases by themselves don’t have the capability to accomplish any task, and they rely on plugins to carry out the task.
• depending on the project and packaging type, Maven binds various plugin goals to lifecycle phases and goals carry out the task entrusted to them.

When we run mvn package in a Java Project, Maven binds plugin goals to lifecycle phases as shown in the figure below:

So to explain a little further as outlined here

Maven builds are split in life-cycles these are:

• clean
• build (default)
• site

Each of this cycles is split into phases. For instance build is split into phases like:

• prepare resources
• compile
• package
• install

Phases have goals to run prior pre- or after post- a phase, for instance:

• pre-clean - will be executed prior the clean phase
• post-clean - will be executed after the clean phase

You can view goals as additional "inserted" phases if you like. Read up here or take a look at @Gerolds answer for details.

LifeCycle vs Phases: Life Cycle is a collection of phases. When you call a phase, it will also call all phases that come before it. Maven comes with 3 built-in build life cycles as:

1. Clean lifecycle- this involves cleaning of the project (for a fresh build & deployment)
2. Default/build lifecycle- this handles the complete deployment of the project
3. Site lifecycle- this handles generating the java documentation of the project.

Clean lifecycle has 3 phases: pre-clean, clean and post-clean. Default and site lifecycles' phases are same as shown in the picture.