What is a Mojo? A simple definition for Mojo is that Mojo is a Maven goal. This is not far from reality.

In order to be more accurate, we can say that a Mojo is a Maven plain Old Java Object. Each Mojo is an executable goal in Maven, and a plugin is a distribution of one or more related Mojos.

In practice, to create a Mojo, we must create a class extending the abstract class, as follows:

org.apache.maven.plugin.AbstractMojo

Such a class provides a utility method for common operations. Furthermore, it provides the abstract method, public void execute() throws MojoExecutionException, to perform all the dirty work when the plugin is executed.

In order to associate our Mojo to a goal for our plugin, we have to use an annotation in Java style on our class definition:

@Mojo(name = "mark-resolved", 
      defaultPhase = LifecyclePhase.PACKAGE, 
      requiresOnline = true, 
      requiresProject = true, 
      threadSafe = true)
public class MarkResolved extends AbstractMojo

With the @Mojo annotation, we indicate that the MarkResolved class is a Mojo, and its goal is mark-resolved. With other parameters of annotation, we specified the default phase when the plugin is executed. In the same annotation, we can indicate other desirable characteristics as follows:

This kind of notation is quite different from the old-fashioned way. The old, and still supported, annotation system provides the use of comments. With such a system, our Mojo definition would look like the following code:

/**
 * @goal mark-resolved 
 * @phase package
 * @requiresOnline true
 * @requiresProject true
 * @threadSafe true
 */
public class MarkResolved extends AbstractMojo

As we can see, the functionality and parameters are the same. The only change is represented by the declaration syntax.

All the plugins have a configuration section in which the users can set parameters used for accomplishing the plugin goal. Parameters can also be passed through the command line:

$ mvn plugin-name:goal -Dmy.custom.parameter=somevalue

In order to match the configuration properties with Mojo's fields, we have to annotate our Mojo fields as follows:

@Parameter( property="basedir", required=true)
protected File baseDir;

The @Parameter annotation's function is to pass the base directory of the project. Within the annotation, we specified the name of the configuration parameter with property="basedir".

We also specified whether the parameter is mandatory or not with the required=true notation.

Our basedir property is automatically injected into our object without the need for other coding. We can thank the Plexus Inversion of Control framework for this.

With the old annotation, we could obtain the same result with the following code:

/**
 * @parameter expression="${basedir}"
 * @required
 */
protected File baseDir;

In this way, all the annotated Mojo fields will be associated with a relative parameter without the need for getter and setter methods.

In order to use a property name different from the field name, we have to indicate the configuration property name used in the plugin configuration. We can do this through the alias="dbUserName" notation.

This indication is not enough; we also have to create a setter for the new aliased property name:

public void setDbUserName(String dbUserName) {
    this.dbUser = dbUserName;
}

Using this method, we can remap the configuration properties on different Mojo field names. With this feature, we can remap private fields that are incomprehensible to users, to friendly name parameters.

Another powerful feature is the capability of assigning a default value if there is no value for nonmandatory parameters:

@Parameter(property="project.desctiption", defaultValue="${project.description}")
protected String projectDesctiption;

We have some specific properties, defined in the Maven's central POM, as follows:

Notice how some of these properties have a common name prefix. Such a prefix is used to specify the scope of the property. So, properties defined at the project level will be prefixed with project, while properties defined in the user's settings.xml file will be prefixed with settings.

The convention for referring to the parent project's variables provides using the ${project.parent} syntax.

Maven also gives users the possibility of defining custom properties. We can simply add a property into our pom.xml file with the following syntax:

<project>
...
 <properties>
   <my.property>hello</my.property>
 </properties>
...
</project>

As we saw before, Maven links each property to a getter/setter method. Thus, properties such as ${project.build.directory} will be matched with the getProject().getBuild().getDirectory()method chain.

The first inherited method that we will see is getLog(). This method returns a logger of type org.apache.maven.plugin.logging.Log. Such a logger allows you to write on output of the plugin's execution. The following line of code will produce the [INFO] Jdbc Driver :: com.mysql.jdbc.Driver output:

log.info("Jdbc Driver :: " + jdbcDriver);

The plugin logger provides three different levels of output: info, error, and debug.

Another inherited method is getPluginContext(). This method returns java.util.Map containing all the property mappings defined in Mojo's context. These mappings contain all the properties explained before, that are visible from Mojo's POM. We can access the basedir property using the following notation:

String baseDir = (String) getPluginContext("basedir");

Using the setter method, we set a custom plugin context to our Mojo, as follows:

public void setPluginContext(Map pluginContext)

We can get the plugin context map using getPluginContext, add some parameters, and set the new map with setPluginContext.