John of All Trades

I just completed a major overhaul[1] of the Maven lifecycle-execution code, and I wanted to take a few minutes to share some of the high-geek-factor features of the new architecture.

First of all, the new architecture builds up a complete list of all the mojos that will fire during your build, along with their configurations…all before it executes the first mojo. This means all plugins in the build will be verified as present and accounted-for right up front. Lifecycle phase bindings are resolved from the POM’s packaging, the POM’s build section, and the command line itself. Then, all of these lifecycle bindings are merged together and injected with their appropriate configurations from the POM and various other places (like lifecycle overlays brought in during forked execution by plugins) to form a BuildPlan instance. Then, the LifecycleExecutor (no, I didn’t completely remove this) extracts a List of bindings from the plan, and iterates over each one, executing as it goes. While just-in-time processes are often viewed as beneficial in many quarters, they are the enemy of predictable builds…and this modification gets rid of them.

Second, the existence of a BuildPlan prior to all mojo execution means that we now have the luxury of printing a step-by-step list of exactly what Maven intends to do during your build. For quick debugging, I’ve included an abbreviated version of this listing in the debug output (-X command-line option of mvn)…just search for ‘Our build plan is:’ to find it in the console output. Also, in order to make Maven a tad more digestible for new users, I’ve written a tiny plugin called the maven-lifecycle-plugin[2] that contains a mojo – called ‘build-plan’, appropriately enough – for exploring the BuildPlan. To print the build plan for your project, simply type the following:

mvn lifecycle:build-plan -Dtasks=clean,package

The output will look similar to the following:

[INFO] [lifecycle:build-plan]
[INFO] 

Project: org.apache.maven.plugins:maven-lifecycle-plugin:maven-plugin:1.0-SNAPSHOT
Tasks: clean,package
Build Plan:

1. org.apache.maven.plugins:maven-clean-plugin:2.1:clean [executionId: default]
2. org.apache.maven.plugins:maven-plugin-plugin:2.2:descriptor [executionId: default]
3. org.apache.maven.plugins:maven-resources-plugin:2.2:resources [executionId: default]
4. org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile [executionId: default]
5. org.apache.maven.plugins:maven-resources-plugin:2.2:testResources [executionId: default]
6. org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile [executionId: default]
7. org.apache.maven.plugins:maven-surefire-plugin:2.3.1-SNAPSHOT:test [executionId: default]
8. org.apache.maven.plugins:maven-jar-plugin:2.1:jar [executionId: default]
9. org.apache.maven.plugins:maven-plugin-plugin:2.2:addPluginArtifactMetadata [executionId: default]

If you have configuration for plugins in your POM, try running with -DextendedInfo=true and see what happens.

The final part of this refactor that has me so excited is the ease with which Maven can support improved control mechanisms for lifecycle bindings. Where users were often plagued by problems with the ordering of mojo bindings within a phase that were brought in through the packaging, ancestry, and build configuration of a POM, the refactored lifecycle architecture allows us to develop a simple BuildPlanModifier implementation to make use of a few small tweaks to the POM syntax[3] and take control of phase ordering!

Resources
1. Binaries and design/other documentation for the 2.1-lifecycle-refactor branch can be found here
2. The maven-lifecycle-plugin is not yet deployed. To check it out and install it, use this SVN URL.
3. For a discussion of how these syntax changes might manifest, see the MAVEN wiki space on docs.codehaus.org, here.

Technorati Tags: code, maven