What are Maven goals and phases and what is their difference?
Goals are executed in phases which help determine the order goals get executed in. The best understanding of this is to look at the default Maven lifecycle bindings which shows which goals get run in which phases by default. The compile
phase goals will always be executed before the test
phase goals, which will always be executed before the package
phase goals and so on.
Part of the confusion is exacerbated by the fact that when you execute Maven you can specify a goal or a phase. If you specify a phase then Maven will run all phases up to the phase you specified in order (e.g. if you specify package it will first run through the compile phase and then the test phase and finally the package phase) and for each phase it will run all goals attached to that phase.
When you create a plugin execution in your Maven build file and you only specify the goal then it will bind that goal to a given default phase. For example, the jaxb:xjc
goal binds by default to the generate-resources
phase. However, when you specify the execution you can also explicitly specify the phase for that goal as well.
If you specify a goal when you execute Maven then it will run that goal and only that goal. In other words, if you specify the jar:jar
goal it will only run the jar:jar
goal to package your code into a jar. If you have not previously run the compile goal or prepared your compiled code in some other way this may very likely fail.
Life cycle is a sequence of named phases.
Phases executes sequentially. Executing a phase means executes all previous phases.Plugin is a collection of goals also called MOJO (Maven Old Java Object).
Analogy : Plugin is a class and goals are methods within the class.
Maven is based around the central concept of a Build Life Cycles. Inside each Build Life Cycles there are Build Phases, and inside each Build Phases there are Build Goals.
We can execute either a build phase or build goal. When executing a build phase we execute all build goals within that build phase. Build goals are assigned to one or more build phases. We can also execute a build goal directly.
There are three major built-in Build Life Cycles:
- default
- clean
- site
Each Build Lifecycle is Made Up of Phases
For example the default
lifecycle comprises of the following Build Phases:
◾validate - validate the project is correct and all necessary information is available
◾compile - compile the source code of the project
◾test - test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed
◾package - take the compiled code and package it in its distributable format, such as a JAR.
◾integration-test - process and deploy the package if necessary into an environment where integration tests can be run
◾verify - run any checks to verify the package is valid and meets quality criteria
◾install - install the package into the local repository, for use as a dependency in other projects locally
◾deploy - done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.
So to go through the above phases, we just have to call one command:
mvn <phase> { Ex: mvn install }
For the above command, starting from the first phase, all the phases are executed sequentially till the ‘install’ phase. mvn
can either execute a goal or a phase (or even multiple goals or multiple phases) as follows:
mvn clean install plugin:goal
However, if you want to customize the prefix used to reference your plugin, you can specify the prefix directly through a configuration parameter on the maven-plugin-plugin
in your plugin's POM.
A Build Phase is Made Up of Plugin Goals
Most of Maven's functionality is in plugins. A plugin provides a set of goals that can be executed using the following syntax:
mvn [plugin-name]:[goal-name]
For example, a Java project can be compiled with the compiler-plugin's compile-goal by running mvn compiler:compile
.
Build lifecycle is a list of named phases that can be used to give order to goal execution.
Goals provided by plugins can be associated with different phases of the lifecycle. For example, by default, the goal compiler:compile
is associated with the compile
phase, while the goal surefire:test
is associated with the test
phase. Consider the following command:
mvn test
When the preceding command is executed, Maven runs all goals associated with each of the phases up to and including the test
phase. In such a case, Maven runs the resources:resources
goal associated with the process-resources
phase, then compiler:compile
, and so on until it finally runs the surefire:test
goal.
However, even though a build phase is responsible for a specific step in the build lifecycle, the manner in which it carries out those responsibilities may vary. And this is done by declaring the plugin goals bound to those build phases.
A plugin goal represents a specific task (finer than a build phase) which contributes to the building and managing of a project. It may be bound to zero or more build phases. A goal not bound to any build phase could be executed outside of the build lifecycle by direct invocation. The order of execution depends on the order in which the goal(s) and the build phase(s) are invoked. For example, consider the command below. The clean
and package
arguments are build phases, while the dependency:copy-dependencies
is a goal (of a plugin).
mvn clean dependency:copy-dependencies package
If this were to be executed, the clean
phase will be executed first (meaning it will run all preceding phases of the clean lifecycle, plus the clean
phase itself), and then the dependency:copy-dependencies
goal, before finally executing the package
phase (and all its preceding build phases of the default lifecycle).
Moreover, if a goal is bound to one or more build phases, that goal will be called in all those phases.
Furthermore, a build phase can also have zero or more goals bound to it. If a build phase has no goals bound to it, that build phase will not execute. But if it has one or more goals bound to it, it will execute all those goals.
Built-in Lifecycle Bindings
Some phases have goals bound to them by default. And for the default lifecycle, these bindings depend on the packaging value.
Maven Architecture:
Reference 1
Reference 2
Eclipse sample for Maven Lifecycle Mapping