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
![enter image description here]()
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).
