Maven 4: Lifecycle

Phases are invisible unless something is bound to them, so every experiment uses the same probe: the Maven Antrun plugin (3.2.0) with one <echo> execution bound to a phase. A probe project binds three executions to each of the 19 phase names of the Maven 4 default lifecycle (before:X, X and after:X), 57 in all, and prints their execution ids and the goals of the real plugins in the order they ran. Two of the 57:

In the traces below an id starting with b- is the before: hook of the phase that follows, m- is an execution bound to the phase itself and a- is the after: hook; resources:resources, compiler:compile and the like are the default goals of the jar packaging. The traces keep only the --- plugin:goal (execution-id) @ project --- lines of the build log (reduced to the id) and are wrapped by hand. The probe project is this page’s own lab setup, not an example from the Maven documentation.

Maven 3 defines the default lifecycle as one ordered list of phases, from validate to deploy. The unknown-phase error of Maven 3.10.0 prints it:

(A sentence of the message was left out.) Maven 4.0.0-rc-7 keeps a list for the command line, but a different one, and the lifecycle behind it is a tree. The same error, provoked with the phase name each:

Three things stand out in that list. Every phase has a before: and an after: form, the old generate-sources, process-resources, prepare-package and friends are gone from it (they still work, as the section on aliases shows) and each is not a phase you can type in rc-7, although all is. The Lifecycles Reference of rc-7 prints the tree itself, from which the table below is taken (the goals are those of the jar packaging, run in the first section).

Two details of the tree deserve emphasis. A ready phase exists because most of what a dependent project needs from a dependency is its compiled classes and resources, not its finished jar, so a dependent can start at ready. And verify runs after validate only: the tree does not say that verification must wait for packaging, which is the difference the concurrent builder makes visible later on this page. The maven-core reference page lists the same tree, including the clean and site lifecycles (site-deploy runs after site).

Source: Maven 4.0.0-rc-7 core reference: default Lifecycle and What’s new in Maven 4: lifecycle changed from graph to tree

Every phase now has a before: and an after: phase to bind to. The probe project (57 executions) was run with mvn verify. Maven 3.10.0, given a POM that is the same except for model version 4.0.0, ran 8 of the 57 and said nothing about the other 49:

Only the executions bound to phases that already exist in Maven 3 ran: validate, initialize, compile, test-compile, test, package, integration-test and verify. An execution bound to before:compile or sources is never bound and the build still ends with BUILD SUCCESS, with no warning. Maven 3.9.16 ran the same 8. Maven 4.0.0-rc-7 ran 47 of the 57 (the 10 missing are the each hooks, all, and the install and deploy ones, which verify does not reach):

What this trace shows:

Running a hook as the goal of the command line behaves like running the phase itself. mvn before:compile, mvn after:compile and mvn compile produced the same trace in this project, all the way to a-build and a-all, including the compiler goal. The same holds for mvn prepare-package (an alias, see below) and mvn before:package: both run the jar goal. Maven 3.10.0 stops prepare-package before jar:jar; in Maven 4 the default builder does not, because the hook always comes with its phase.

This is the behaviour change that the overview page calls "phase execution scope": the after: hook of a phase you reach always runs, so a plugin bound to post-clean runs on mvn clean.

Source: What’s new in Maven 4: before- and after-phases and Behavioral change: phase execution scope

Several executions can be bound to the same phase, and in Maven 3 they run in the order the plugins and executions are declared in the POM. Maven 4 lets you add an integer in square brackets to the phase name, a priority. The experiment binds ten executions of the Antrun plugin to compile and its hooks, in a scrambled order in the POM (the execution ids e1 to e10 are their declaration order):

Each execution echoes its id and phase. mvn compile on rc-7 printed (the (compiler:compile) line stands for the log line of the compiler goal):

The rules the output demonstrates:

The Maven 4 plugin descriptor META-INF/maven/lifecycle.xml (used by plugins that define their own lifecycle) has the same concept under another name: a <phase> element takes an executionPoint attribute (such as before or after, which decorates the phase named by <id>) and a priority, an integer whose default is 0. That default matches the unnumbered executions above.

Maven 3.10.0 and 3.9.16 do not know the syntax: running the same project on both printed only e1 compile after the compiler goal, so the other nine executions, the numbered ones and the hooks, were never bound and the build still succeeded. The overview page measured the same for validate[200], so do not use a bracketed phase in a POM that must still build with Maven 3. Section The concurrent builder adds that the concurrent builder of rc-7 also ignores the numbered executions.

Source: What’s new in Maven 4: ordering of executions and Maven 4.0.0-rc-7 plugin API reference: Lifecycle descriptor

Maven 3 had a few phases named pre-* and post-* and many with the generate-*, process-* and prepare-package names. In Maven 4 they survive as aliases of tree phases, and the release notes warn against binding to them. To see which phase each alias maps to, a probe project bound one execution to each old name and one to its target, and ran mvn verify. Each pair fired back to back, which gave this table (for the clean and site lifecycles the pairs are pre-clean with before:clean, post-clean with after:clean, pre-site with before:site and post-site with after:site):

The experiment’s trace, reduced to the old and new names and the real goals (each pair appeared in this order):

The command line accepts the same aliases: mvn process-classes ran resources:resources and compiler:compile, like mvn after:compile. The warning of the official article applies to the post-* names above all: a plugin bound to process-resources, because there is no pre-compile, is really bound to after:resources, which may not be what its author meant. For the migration step that replaces the names, with mvnup, see Migrating to Maven 4; the migration guide lists the replacement of pre-integration-test and post-integration-test with before:integration-test and after:integration-test as a required change of step 2.

Source: Maven 4 migration guide: replace plugin bindings to pre- and post- lifecycle phases

The tree only changes how a build runs when you ask for it. Maven picks a builder, the strategy that walks the reactor and the phases, and rc-7 has three. -b or --builder selects one by id (the option text is the same in Maven 3.10.0 and rc-7: "The id of the build strategy to use"):

An unknown id fails at once. Maven 3.10.0 for -b concurrent and rc-7 for -b nonesuch:

The concurrent builder is the only one that plans the build from the tree. It computes, for the phase you requested, the phases that it depends on, in all the projects, and runs whatever is ready. Everything that follows on this page about "concurrent" is that builder; the flag does nothing else.

The Ant model is on Ant Targets & Extension Points and the Gradle one on Gradle Build Lifecycle.