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 expression="${...}". 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 expression="${project}") and dependency is instance of Dependency (@parameter expression="${project.dependencies}).
