----------------------------------------------------------------------------------------------------------------------------------
Install an artifact with a custom POM
The install plugin can include a pre-built custom POM with the artifact in the local repository. Just set the value of the pomFile parameter to the path of the custom POM.
mvn install:install-file -Dfile=path-to-your-artifact-jar "
-DgroupId=your.groupId "
-DartifactId=your-artifactId "
-Dversion=version "
-Dpackaging=jar "
-DpomFile=path-to-pom
----------------------------------------------------------------------------------------------------------------------------------
Generate a generic POM
There are times when you do not have a POM for a 3rd party artifact. For instance, when installing a proprietary or commercial JAR into a repository. The install plugin can create a generic POM in this case which contains the minimal set of POM elements required by Maven, such as groupId, artifactId, version, packaging. You tell Maven to generate a POM by setting the generatePom parameter to true.
mvn install:install-file -Dfile=path-to-your-artifact-jar "
-DgroupId=your.groupId "
-DartifactId=your-artifactId "
-Dversion=version "
-Dpackaging=jar "
-DgeneratePom=true
----------------------------------------------------------------------------------------------------------------------------------
Creating artifact checksums
The install plugin can create integrity checksums (MD5, SHA-1) for the artifacts during installation. Checksums are cryptographic hash functions and are used to check the integrity of the associated file. This can be activated by setting the createChecksum parameter to true.
In the install:install mojo.
mvn install -DcreateChecksum=true
In the install:install-file goal.
mvn install:install-file -Dfile=path-to-your-artifact-jar "
-DgroupId=your.groupId "
-DartifactId=your-artifactId "
-Dversion=version "
-Dpackaging=jar "
-DcreateChecksum=true
----------------------------------------------------------------------------------------------------------------------------------
Update the release information of a project
Updating the release information means that a forced update of the project's metadata took place which sets the artifact as the release version. It is most useful when installing a plugin built from source so it can be used by other projects without explicitly asking for the latest SNAPSHOT version.
This can be activated by setting the updateReleaseInfo parameter to true when installing.
mvn install -DupdateReleaseInfo=true
----------------------------------------------------------------------------------------------------------------------------------
Install on a specific local repository path
By default, Maven Install Plugin uses the local repository defined in the settings.xml to install an artifact.
You could install an artifact on a specific local repository by setting the localRepositoryPath and localRepositoryId parameters when installing.
mvn install:install-file -Dfile=path-to-your-artifact-jar "
-DgroupId=your.groupId "
-DartifactId=your-artifactId "
-Dversion=version "
-Dpackaging=jar "
-DpomFile=path-to-pom "
-DlocalRepositoryPath=path-to-specific-local-repo "
-DlocalRepositoryId=id-for-specific-local-repo
----------------------------------------------------------------------------------------------------------------------------------
Delete Additional Files Not Exposed to Maven
The maven-clean-plugin will delete the target directory by default. You may configure it to delete additional directories and files. The following example shows how:
<build>
[...]
<plugin>
<artifactId>maven-clean-plugin</artifactId>
<configuration>
<filesets>
<fileset>
<directory>some/relative/path</directory>
<includes>
<include>**/*.tmp</include>
<include>**/*.log</include>
</includes>
<excludes>
<exclude>**/important.log</exclude>
<exclude>**/another-important.log</exclude>
</excludes>
<followSymlinks>false</followSymlinks>
</fileset>
</filesets>
</configuration>
</plugin>
[...]
</build>
Note: The directory in the fileset is a relative path inside a project, in other words,
<directory>some/relative/path</directory>
is equivalent to:
<directory>${basedir}/some/relative/path</directory>
You could also define file set rules in a parent POM. In this case, the clean plugin adds the subproject basedir to the defined relative path.
----------------------------------------------------------------------------------------------------------------------------------
Ignoring Clean Errors
To ignore errors when running the cleanup for a particular project, set the failOnError property to false.
<build>
[...]
<plugin>
<artifactId>maven-clean-plugin</artifactId>
<configuration>
<failOnError>false</failOnError>
</configuration>
</plugin>
[...]
</build>
You can also ignore them via command line by executing the following command:
mvn clean -Dmaven.clean.failOnError=false
----------------------------------------------------------------------------------------------------------------------------------
Skipping Clean
To skip running the cleanup for a particular project, set the skip property to true.
<build>
[...]
<plugin>
<artifactId>maven-clean-plugin</artifactId>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
[...]
</build>
You can also skip the cleaning via command line by executing the following command:
mvn clean -Dclean.skip=true
----------------------------------------------------------------------------------------------------------------------------------
Compiling Sources Using A Different JDK
The compilerVersion parameter can be used to specify the version of the compiler that the plugin will use. However, you also need to set fork to true for this to work. For example:
<project>
[...]
<build>
[...]
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<verbose>true</verbose>
<fork>true</fork>
<executable><!-- path-to-javac --></executable>
<compilerVersion>1.3</compilerVersion>
</configuration>
</plugin>
</plugins>
[...]
</build>
[...]
</project>
To avoid hard-coding a filesystem path for the executable, you can use a property. For example:
<executable>${JAVA_1_4_HOME}/bin/javac</executable>
Each developer then defines this property in settings.xml, or sets an environment variable, so that the build remains portable.
<settings>
[...]
<profiles>
[...]
<profile>
<id>compiler</id>
<properties>
<JAVA_1_4_HOME>C:"Program Files"Java"j2sdk1.4.2_09</JAVA_1_4_HOME>
</properties>
</profile>
</profiles>
[...]
<activeProfiles>
<activeProfile>compiler</activeProfile>
</activeProfiles>
</settings>
----------------------------------------------------------------------------------------------------------------------------------
Setting the -source and -target of the Java Compiler
Sometimes when you may need to compile a certain project to a different version than what you are currently using. The javac can accept such command using -source and -target. The Compiler Plugin can also be configured to provide these options during compilation.
For example, if you want to enable assertions (-source 1.4) and also want the compiled classes to be compatible with JVM 1.4 (-target 1.4), you can then put:
<project>
[...]
<build>
[...]
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.4</source>
<target>1.4</target>
</configuration>
</plugin>
</plugins>
[...]
</build>
[...]
</project>
----------------------------------------------------------------------------------------------------------------------------------
Compile Using Memory Allocation Enhancements
The Compiler Plugin accepts configurations for meminitial and maxmem. You can follow the example below to set the initial memory size to 128MB and the maximum memory usage to 512MB:
<project>
[...]
<build>
[...]
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<fork>true</fork>
<meminitial>128m</meminitial>
<maxmem>512m</maxmem>
</configuration>
</plugin>
</plugins>
[...]
</build>
[...]
</project>
----------------------------------------------------------------------------------------------------------------------------------
Pass Compiler Arguments
Sometimes, you need to pass other compiler arguments that are not handled by the Compiler Plugin itself but is supported by the compilerId selected. For such arguments, the Compiler Plugin's compilerArguments will be used. The following example passes compiler arguments to the javac compiler:
<project>
[...]
<build>
[...]
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<compilerArgument>-verbose -bootclasspath ${java.home}"lib"rt.jar</compilerArgument>
</configuration>
</plugin>
</plugins>
[...]
</build>
[...]
</project>
Or you can also use the Map version:
<project>
[...]
<build>
[...]
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<compilerArguments>
<verbose />
<bootclasspath>${java.home}"lib"rt.jar</bootclasspath>
</compilerArguments>
</configuration>
</plugin>
</plugins>
[...]
</build>
[...]
</project>
----------------------------------------------------------------------------------------------------------------------------------
Deployment of artifacts with FTP
In order to deploy artifacts using FTP you must first specify the use of an FTP server in the distributionManagement element of your POM as well as specifying an extension in your build element which will pull in the FTP artifacts required to deploy with FTP:
<project>
<parent>
<groupId>com.stchome</groupId>
<artifactId>mavenFull</artifactId>
<version>1.0</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany</groupId>
<artifactId>my-app</artifactId>
<packaging>jar</packaging>
<version>1.1-SNAPSHOT</version>
<name>Maven Quick Start Archetype</name>
<url>http://maven.apache.org</url>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
<!-- Enabling the use of FTP -->
<distributionManagement>
<repository>
<id>ftp-repository</id>
<url>ftp://repository.mycompany.com/repository</url>
</repository>
</distributionManagement>
<build>
<extensions>
<extension>
<groupId>org.apache.maven.wagon</groupId>
<artifactId>wagon-ftp</artifactId>
<version>1.0-alpha-6</version>
</extension>
</extensions>
</build>
</project>
Your settings.xml would contain a server element where the id of that element matches id of the FTP repository specified in the POM above:
<settings>
...
<servers>
<server>
<id>ftp-repository</id>
<username>user</username>
<password>pass</password>
</server>
</servers>
...
</settings>
You should, of course, make sure that you can login into the specified FTP server by hand before attempting the deployment with Maven. Once you have verified that everything is setup correctly you can now deploy your artifacts using Maven:
mvn deploy
----------------------------------------------------------------------------------------------------------------------------------
Deployment of artifacts in an external SSH command
In order to deploy artifacts using SSH you must first specify the use of an SSH server in the distributionManagement element of your POM as well as specifying an extension in your build element which will pull in the SSH artifacts required to deploy with SSH:
<project>
<parent>
<groupId>com.stchome</groupId>
<artifactId>mavenFull</artifactId>
<version>1.0</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany</groupId>
<artifactId>my-app</artifactId>
<packaging>jar</packaging>
<version>1.1-SNAPSHOT</version>
<name>Maven Quick Start Archetype</name>
<url>http://maven.apache.org</url>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
<!-- Enabling the use of FTP -->
<distributionManagement>
<repository>
<id>ssh-repository</id>
<url>scpexe://repository.mycompany.com/repository</url>
</repository>
</distributionManagement>
<build>
<extensions>
<extension>
<groupId>org.apache.maven.wagon</groupId>
<artifactId>wagon-ssh-external</artifactId>
<version>1.0-alpha-5</version>
</extension>
</extensions>
</build>
</project>
If you are deploying from Unix or have Cygwin installed you won't need to any additional configuration in your settings.xml file as everything will be taken from the environment. But if you are on Windows and are using something like plink then you will need something like the following:
<settings>
...
<servers>
<server>
<id>ssh-repository</id>
<username>your username in the remote system if different from local</username>
<privateKey>/path/to/your/private/key</privateKey> <!-- not needed if using pageant -->
<configuration>
<sshExecutable>plink</sshExecutable>
<scpExecutable>pscp</scpExecutable>
<sshArgs>other arguments you may need</sshArgs>
</configuration>
</server>
</servers>
...
</settings>
You should, of course, make sure that you can login into the specified SSH server by hand before attempting the deployment with Maven. Once you have verified that everything is setup correctly you can now deploy your artifacts using Maven:
mvn deploy
Sometimes you may have permissions problems deploying and if so you can set the file and directory permissions like so:
<settings>
...
<servers>
<server>
<id>ssh-repository</id>
<!--
|
| Change default file/dir permissions
|
-->
<filePermissions>664</filePermissions>
<directoryPermissions>775</directoryPermissions>
<configuration>
<sshExecutable>plink</sshExecutable>
<scpExecutable>pscp</scpExecutable>
</configuration>
</server>
</servers>
...
</settings>
----------------------------------------------------------------------------------------------------------------------------------
Disable the generation of pom
By default, If no pom is specified during deployment of your 3rd party artifact, a generic pom will be generated which contains the minimum required elements needed for the pom. In order to disable it, set the generatePom parameter to false.
mvn deploy:deploy-file -Durl=file://C:"m2-repo "
-DrepositoryId=some.id "
-Dfile=path-to-your-artifact-jar "
-DgroupId=your.groupId "
-DartifactId=your-artifactId "
-Dversion=version "
-Dpackaging=jar "
-DgeneratePom=false
----------------------------------------------------------------------------------------------------------------------------------
Deploy an artifact with a customed pom
If there is already an existing pom and want it to be deployed together with the 3rd party artifact, set the pomFile parameter to the path of the pom.xml.
mvn deploy:deploy-file -Durl=file://C:"m2-repo "
-DrepositoryId=some.id "
-Dfile=path-to-your-artifact-jar "
-DpomFile=path-to-your-pom.xml
Note that the groupId, artifactId, version and packaging informations are automatically retrieved from the given pom.
----------------------------------------------------------------------------------------------------------------------------------
Deploy an artifact with classifier
Classifiers are the additional text given to describe an artifact.
artifact-name-1.0-bin.jar
artifact-name-1.0-dev.jar
artifact-name-1.0-prod.jar
From the above artifact names, classifiers can be located between the version and extension name of the artifact.
bin is used to describe that the artifact is a binary.
dev is used to describe that the artifact is for development.
prod is used to describe that the artifact is for production.
To add classifier into your artifact for your deployment, set the text to the classifier parameter.
mvn deploy:deploy-file -Durl=file://C:"m2-repo "
-DrepositoryId=some.id "
-Dfile=path-to-your-artifact-jar "
-DpomFile=path-to-your-pom.xml "
-Dclassifier=bin
----------------------------------------------------------------------------------------------------------------------------------
Disable timestamps suffix in an artifact
By default, when a snapshot version of an artifact is deployed to a repository, a timestamp is suffixed to it. To disable the addition of timestamp to the artifact, set the uniqueVersion parameter to false.
mvn deploy:deploy-file -Durl=file://C:"m2-repo "
-DrepositoryId=some.id "
-Dfile=your-artifact-1.0.jar "
-DpomFile=your-pom.xml "
-DuniqueVersion=false
----------------------------------------------------------------------------------------------------------------------------------
Deploy an artifact in legacy layout
"Legacy" is the layout used in maven 1 repositories while maven 2 uses "default". They are different in terms of directory structure, timestamp of snapshots in default and existence of metadata files in default.
legacy layout directory structure:
groupId
|--artifactId
|--jars
`--artifact
default layout directory structure:
groupId
|--artifactId
|--version
| `---artifact
|---metadata
In able to deploy an artifact in a legacy layout of repository, set the repositoryLayout parameter to legacy value.
mvn deploy:deploy-file -Durl=file://C:"m2-repo "
-DrepositoryId=some.id "
-Dfile=your-artifact-1.0.jar "
-DpomFile=your-pom.xml "
-DrepositoryLayout=legacy
----------------------------------------------------------------------------------------------------------------------------------
| Plugin
|
Version
|
Description
|
| core plugins
|
|
Plugins corresponding to default core phases (ie. clean, compile). They may have muliple goals as well.
|
| clean
|
2.2 |
Clean up after the build. |
| compiler
|
2.0.2 |
Compiles Java sources. |
| deploy
|
2.3 |
Deploy the built artifact to the remote repository. |
| install
|
2.2 |
Install the built artifact into the local repository. |
| resources
|
2.2 |
Copy the resources to the output directory for including in the JAR. |
| site
|
2.0-beta-6 |
Generate a site for the current project. |
| surefire
|
2.3 |
Run the Junit tests in an isolated classloader. |
| verifier
|
1.0-beta-1 |
Useful for integration tests - verifies the existence of certain conditions. |
| packaging types / tools
|
|
These plugins relate to packaging respective artifact types.
|
| ear
|
2.3.1 |
Generate an EAR from the current project. |
| ejb
|
2.1 |
Build an EJB (and optional client) from the current project. |
| jar
|
2.1 |
Build a JAR from the current project. |
| rar
|
2.2 |
Build a RAR from the current project. |
| war
|
2.1-alpha-1 |
Build a WAR from the current project. |
| reporting
|
|
Plugins which generate reports, are configured as reports in the POM and run under the site generation lifecycle.
|
| changelog
|
2.1 |
Generate a list of recent changes from your SCM. |
| changes
|
2.0-beta-3 |
Generate a report from issue tracking or a change document. |
| checkstyle
|
2.1 |
Generate a checkstyle report. |
| clover
|
2.4 |
Generate a Clover report. NOTE: Moved to Atlassian.com |
| doap
|
1.0-beta-1 |
Generate a Description of a Project (DOAP) file from a POM. |
| docck
|
1.0-beta-2 |
Documentation checker plugin. |
| javadoc
|
2.3 |
Generate Javadoc for the project. |
| jxr
|
2.1 |
Generate a source cross reference. |
| pmd
|
2.2 |
Generate a PMD report. |
| project-info-reports
|
2.0.1 |
Generate standard project reports. |
| surefire-report
|
2.3 |
Generate a report based on the results of unit tests. |
| tools
|
|
These are miscellaneous tools available through Maven by default.
|
| ant
|
2.0 |
Generate an Ant build file for the project. |
| antrun
|
1.1 |
Run a set of ant tasks from a phase of the build. |
| archetype
|
1.0-alpha-7 |
Generate a skeleton project structure from an archetype. |
| assembly
|
2.2-beta-1 |
Build an assembly (distribution) of sources and/or binaries. |
| dependency
|
2.0-alpha-4 |
Dependency manipulation (copy, unpack) and analysis. |
| enforcer
|
1.0-alpha-3 |
Environmental constraint checking (Maven Version, JDK etc), User Custom Rule Execution. |
| gpg
|
1.0-alpha-4 |
Create signatures for the artifacts and poms |
| help
|
2.0.2 |
Get information about the working environment for the project. |
| invoker
|
1.1 |
Run a set of Maven projects and verify the output |
| one
|
1.2 |
A plugin for interacting with legacy Maven 1.x repositories and builds. |
| patch
|
1.0 |
Use the gnu patch tool to apply patch files to source code. |
| plugin
|
2.3 |
Create a Maven plugin descriptor for any Mojo's found in the source tree, to include in the JAR. |
| release
|
2.0-beta-7 |
Release the current project - updating the POM and tagging in the SCM. |
| remote-resources
|
1.0-alpha-6 |
Copy remote resources to the output directory for inclusion in the artifact. |
| repository
|
2.0 |
Plugin to help with repository-based tasks. |
| scm
|
1.0 |
Generate a SCM for the current project. |
| source
|
2.0.4 |
Build a JAR of sources for use in IDEs and distribution to the repository. |
| IDEs
|
|
Plugins that simplify integration with integrated developer environments.
|
| eclipse
|
2.4 |
Generate an Eclipse project file for the current project. |
| idea
|
2.1 |
Create/update an IDEA workspace for the current project (individual modules are created as IDEA modules) |
There are also many plug-ins available at the Mojo
project at Codehaus. To see the most up-to-date list browse the Codehaus repository at http://repository.codehaus.org/
, specifically the org/codehaus/mojo
subfolder. Here are a few common ones:
| Plugin
|
Version
|
Description
|
| build-helper
|
1.0 |
Attach extra artifacts and source folders to build. |
| castor
|
1.0 |
Generate sources from an XSD using Castor. |
| javacc
|
2.1 |
Generate sources from a JavaCC grammer. |
| jdepend
|
2.0-beta-1 |
Generate a report on code metrics using JDepend. |
| native
|
1.0-alpha-2 |
Compiles C and C++ code with native compilers. |
| sql
|
1.0 |
Executes SQL scripts from files or inline. |
| taglist
|
2.1 |
Generate a list of tasks based on tags in your code. |
A number of other projects provide their own Maven2 plugins. This includes:
| Plugin
|
Description
|
| cargo
|
Start/stop/configure J2EE containers and deploy to them. |
| jaxme
|
Use the JaxMe JAXB implementation to generate Java sources from XML schema. |
| jetty
|
Run a Jetty container for rapid webapp development. |
| jalopy
|
Use Jalopy to format your source code |