Skip to end of metadata
Go to start of metadata

Mojo Developer Cookbook

 This page contains code snippets demonstrating commonly used tasks when writing Maven plug-ins. There are no guarantees that these are the 'right' way to do things, but they have worked at least once for the author(s).

Commonly used components 

These components are commonly used, also in the following snippets.

The maven project, or the effective pom.

With the MavenProject object, you would be able to access a lot of things ( that is if you don't know the @component or @expression for it.




Creating a maven project





The dependencies declared in your plugin.





For accessing artifacts and repositories





For resolving artifact verions




Deploying and installing



You may want to add @required and @readonly, but I dropped them to keep it short.

The ones listed here are the common ones. But you can use other properties in default-value="${...}". See MavenPropertiesGuide for more info...

Dependencies for Components

When developing with the above mentioned commonly used components you will
want to add the following dependencies to your pom.xml:




Storing Properties

 If you want to store properties in your mojo and make those properties accessible to other elements ( such as plugins, resource files, etc ). You can do something like this


This is like adding to your pom




Creating and resolving an artifact

 To create an artifact, use an ArtifactFactory.


An artifact doesn't help you much until it's resolved (using an ArtifactResolver). This resolving process is not transitive!


Now you get the artifact file (in the local repository):



Resolving an artifact from a version range

First you need to create the version range:

Then you need to create the artifact from the version range:

Once you have the artifact with version range you use the ArtifactMetadataSource to retrieve the versions:

Then you can parse the list of versions and find the version that you are after (for example using versionRange.matchVersion) and then create a new artifact using tha version.


Resolving transitively

You need a MavenProject. If you don't have (the right) one, you can create it with just a groupId:artifactId:version:


Now you can use the ArtifactResolver to resolve transitively.


The filter is optional, and limits the resolving. Possible filters are:

  • ScopeArtifactFilter
  • InclusionArtifactFilter
  • ExclusionArtifactFilter
  • TypeArtifactFilter
  • AndArtifactFilter (to combine them)
  • or create your own, by implementing ArtifactFilter

Running external commands

Use CommandLine and CommandLineUtils from org.codehaus.plexus.util.cli


The input parameter is optional. For the output and error StreamConsumers, you can use CommandLineUtils.StringStreamConsumer which captures the output
in a String.

Installing and deploying artifacts

If you need want to install or deploy an artifact as part of a project build, you can add them to the MavenProject and they will be picked up in the install or deploy phase.


If you install/deploy in a standalone goal, or you need to install/deploy an artifact that is not part of the project being built, you can use the ArtifactInstaller or ArtifactDeployer.




Creating an ArtifactRepository

Usually an artifact repository will be injected into your mojo. Should you need to create one yourself, you will need an ID, a URL and a layout.




Accessing the Plexus container

If you want access to the container, for doing your own component lookups, implement the org.codehaus.plexus.personality.plexus.lifecycle.phase.Contextualizable interface

So if you want to lookup a component, you can do something like this

Getting dependency artifact path

In some cases you may need to get the path of a jar artifact from a Dependency. This is how you can do it:


In this snippet, project is the MavenProject instance of the project (@parameter default-value="${project}") and dependency is instance of Dependency (@parameter default-value="${project.dependencies}).

  • No labels