A Review of the Plugin Terminology

Before delving into the details of how Maven plugins function and how they are written, let’s begin by reviewing the terminology used to describe a plugin and its role in the build.

A mojo is the basic unit of work in the Maven application. It executes an atomic build task that represents a single step in the build process. Each mojo can leverage the rich infrastructure provided by Maven for loading projects, resolving dependencies, injecting runtime parameter information, and more. When a number of mojos perform related tasks, they are packaged together into a plugin.

Just like Java packages, plugins provide a grouping mechanism for multiple mojos that serve similar functions within the build life cycle. For example, the maven-compiler-plugin incorporates two mojos: compile and testCompile. In this case, the common theme for these tasks is the function of compiling code. Packaging these mojos inside a single plugin provides a consistent access mechanism for users, allowing shared configuration to be added to a single section of the POM. Additionally, it enables these mojos to share common code more easily.

Recall that a mojo represents a single task in the build process. Correspondingly, the build process for a project comprises a set of mojos executing in a particular, well-defined order. This ordering is called the build life cycle, and is defined as a set of task categories, called phases. When Maven executes a build, it traverses the phases of the life cycle in order, executing all the associated mojos at each phase of the build.

This association of mojos to phases is called binding and is described in detail below.

Together with phase binding, the ordered execution of Maven’s life cycle gives coherence to the build process, sequencing the various build operations. While Maven does in fact define three different life-cycles, the discussion in this chapter is restricted to the default life cycle, which is used for the majority of build activities (the other two life cycles deal with cleaning a project’s work directory and generating a project Web site). A discussion of all three build life cycles can be found in Appendix A.

Most mojos fall into a few general categories, which correspond to the phases of the build life cycle. As a result, mojos have a natural phase binding which determines when a task should execute within the life cycle. Since phase bindings provide a grouping mechanism for mojos within the life cycle, successive phases can make assumptions about what work has taken place in the previous phases. Therefore, to ensure compatibility with other plugins, it is important to provide the appropriate phase binding for your mojos.

While mojos usually specify a default phase binding, they can be bound to any phase in the life cycle. Indeed, a given mojo can even be bound to the life cycle multiple times during a single build, using the plugin executions section of the project’s POM. Each execution can specify a separate phase binding for its declared set of mojos. However, before a mojo can execute, it may still require that certain activities have already been completed, so be sure to check the documentation for a mojo before you re-bind it.

In some cases, a mojo may be designed to work outside the context of the build life cycle. Such mojos may be meant to check out a project from version control, or even create the directory structure for a new project. These mojos are meant to be used by way of direct invocation, and as such, will not have a life-cycle phase binding at all since they don’t fall into any natural category within a typical build process. Think of these mojos as tangential to the the Maven build process, since they often perform tasks for the POM maintainer, or aid integration with external development tools.