Brief examples on how to use the dependency goals.
See the following links for information about including and configuring plugins in your project:
This goal is meant to be bound to a lifecycle phase and configured in your pom.xml. It will resolve the artifact from the repository and place a copy in the specified location. Multiple artifacts can be defined in a single execution. A default output directory is specified but can be overridden for each ArtifactItem by setting the optional outputDirectory field. An optional new name can be set to rename or the version stripped while copying.
The artifact version is optional. If not set, the plugin will attempt to resolve it from the project dependencies and then the dependencyManagement section.
See the Overwrite Rules section for rules about how overwriting is handled.
Configure the plugin something like this if you intend to bind it to execute along with your build:
<project>
[...]
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.10</version>
<executions>
<execution>
<id>copy</id>
<phase>package</phase>
<goals>
<goal>copy</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>[ groupId ]</groupId>
<artifactId>[ artifactId ]</artifactId>
<version>[ version ]</version>
<type>[ packaging ]</type>
<classifier> [classifier - optional] </classifier>
<overWrite>[ true or false ]</overWrite>
<outputDirectory>[ output directory ]</outputDirectory>
<destFileName>[ filename ]</destFileName>
</artifactItem>
</artifactItems>
<!-- other configurations here -->
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
[...]
</project>If you intend to configure this mojo for execution on the command line using:
mvn dependency:copy
you must not put the configuration inside the executions tag. Your configuration should look like this:
<project>
[...]
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.10</version>
<configuration>
<artifactItems>
<artifactItem>
<groupId>[ groupId ]</groupId>
<artifactId>[ artifactId ]</artifactId>
<version>[ version ]</version>
<type>[ packaging ]</type>
<classifier> [classifier - optional] </classifier>
<overWrite>[ true or false ]</overWrite>
<outputDirectory>[ output directory ]</outputDirectory>
<destFileName>[ filename ]</destFileName>
</artifactItem>
</artifactItems>
<!-- other configurations here -->
</configuration>
</plugin>
</plugins>
</build>
[...]
</project>Notes:
This goal can be bound to a lifecycle phase and configured in your pom.xml. It will resolve the dependencies (including transitive dependencies) from the repository and place a copy in the specified location.
The artifacts can be placed in subfolders based on type. For example:
\outputDirectory
\outputDirectory\jars
\outputDirectory\wars
The artifacts can be placed in a subfolder per artifact. For example: \outputDirectory\junit-junit-3.8.1
This feature also works with the subfolders per type. For example: \outputDirectory\jars\junit-junit-3.8.1\
Artifacts can also be resolved by specifying the classifier and optionally type. Type is only used with the classifier and defaults to java-sources. When the classifier is set, the list of dependencies is used as the base to resolve artifacts with the classifier and type. For example: mvn dependency:copy-dependencies -Dclassifier=sources will try to find the sources for all dependencies and copy them.
Also included is the ability to include or exclude by type (war, jar etc), scope (runtime, test, etc), classifier (jdk14, sources, etc), groupId, artifactId, or a combination of them.
Note: As of 2.0-alpha-5, you may mix includes and excludes of the same category (ie scope). Includes are processed before excludes.
See the Overwrite Rules section for rules about how overwriting is handled.
The goal can also be launched from the command line like: mvn dependency:copy-dependencies [optional params]
<project>
[...]
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.10</version>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<!-- configure the plugin here -->
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
[...]
</project>This goal is meant to be bound to a lifecycle and configured in your pom.xml. It will resolve the artifact from the repository and place a copy in the specified location. Multiple artifacts can be defined in a single execution. A default outputDirectory is specified but can be overridden for each ArtifactItem by setting the optional outputDirectory field.
A single artifact can be unpacked multiple times if different include/exclude parameters are defined for each artifactItem
See the Overwrite Rules section for rules about how overwriting is handled.
The artifact version is optional. If not set, the plugin will attempt to resolve it from the project dependencies and then the dependencyManagement section.
Configure the plugin something like this if you intend to bind it to execute along with your build:
<project>
[...]
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.10</version>
<executions>
<execution>
<id>unpack</id>
<phase>package</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<!-- configure the plugin here -->
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
[...]
</project>If you intend to configure this mojo for execution on the command line using:
mvn dependency:unpack
you must not put the configuration inside the executions tag. Your configuration should look like this:
<project>
[...]
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.10</version>
<configuration>
<artifactItems>
<artifactItem>
<groupId>[ groupId ]</groupId>
<artifactId>[ artifactId ]</artifactId>
<version>[ version ]</version>
<type>[ packaging ]</type>
<classifier> [classifier - optional] </classifier>
<overWrite>[ true or false ]</overWrite>
<outputDirectory>[ output directory ]</outputDirectory>
<includes>[ comma separated list of file filters ]</includes>
<excludes>[ comma separated list of file filters ]</excludes>
</artifactItem>
</artifactItems>
<!-- other configurations here -->
</configuration>
</plugin>
</plugins>
</build>
[...]
</project>This goal can be bound to a lifecycle and configured in your pom.xml. It will resolve the dependencies (including transitive dependencies) from the repository and unpack them to the specified location.
Unpack-dependencies includes transitive dependencies by default. To include only direct dependencies, set the excludeTransitive parameter to true.
Dependencies can be included or excluded by a list of types. See unpack-dependencies for details.
The artifacts can be unpacked in subfolders based on type. For example:
\outputDirectory
\outputDirectory\jars
\outputDirectory\wars
The artifacts can be placed in a subfolder per artifact. For example: \outputDirectory\junit-junit-3.8.1
This feature also works with the subfolders per type. For example: \outputDirectory\jars\junit-junit-3.8.1\
Artifacts can also be resolved by specifying the classifier and optionally type. Type is only used with the classifier and defaults to java-sources. When the classifier is set, the list of dependencies is used as the base to resolve artifacts with the classifier and type. For example: mvn dependency:unpack-dependencies -Dclassifier=sources will try to find the sources for all dependencies and unpack them.
Filters can be applied to include or exclude certain file or filesets as necessary
Also included is the ability to include or exclude by type (war, jar etc), scope (runtime, test, etc), classifier (jdk14, sources, etc), groupId, artifactId, or a combination of them.
Note: As of 2.0-alpha-5, you may mix includes and excludes of the same category (ie scope). Includes are processed before excludes.
See the Overwrite Rules section for rules about how overwriting is handled.
The goal can also be launched from the command line like: mvn dependency:unpack-dependencies [optional params]
<project>
[...]
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.10</version>
<executions>
<execution>
<id>unpack-dependencies</id>
<phase>package</phase>
<goals>
<goal>unpack-dependencies</goal>
</goals>
<configuration>
<!-- configure the plugin here -->
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
[...]
</project>Artifacts are copied or unpacked using the following rules:
Otherwise:
Examples:
Resolve is intended to be used from the command line like: mvn dependency:resolve -Dsilent=true
This goal simply tells maven to resolve all test scope (includes compile) dependencies and then displays the resolved versions. This is intended to help ensure all dependencies are downloaded to the local repository. This is useful when troubleshooting or during intermittent remote repository failures when repeatedly building multiproject modules is undersirable and the build is failing on dependency resolution. It can also be used to quickly determine how versions are being resolved.
Artifacts can also be resolved by specifying the classifer and optionally type. Type is only used with the classifier and defaults to java-sources. When the classifier is set, the list of dependencies is used as the base to resolve artifacts with the classifer and type. For example: mvn dependency:resolve -Dclassifer=test-jar will try to find the test-jar for all dependencies resolve them to the local repository.
Sources is intended to be used from the command line like: mvn dependency:sources -Dsilent=true
This is the same as the resolve goal except it includes the source attachments if they exist. This is useful when you want the source attachments downloaded to your local repository and you don't want to use the eclipse plugin to do this since the eclipse plugin creates/overwrites the eclipse files.
You can also define the markersDirectory either in the pom or settings to be a common location for all projects. This allows the system to resolve sources faster for dependencies that don't have the sources published. The plugin will store a marker file to describe if the sources were resolved or not. By placing them in a common location, multiple attempts to resolve non-existent sources will be avoided.
Resolve-plugins is intended to be used from the command line like: mvn dependency:resolve-plugins -Dsilent=true -DexcludeTransitive=true
This is the same as the resolve goal except it resolves plugins and optionally their dependencies.
This goal is exactly the same as calling mvn dependency:resolve dependency:resolve-plugins.
This goal is meant to delete all of the dependencies for the current project (or projects, in the case of a multimodule build) from the local repository. Purges can be run with a variety of limiting parameters, including artifact exclusions, limiting to direct dependencies only, and different levels of depth for deletion. By default, deleted artifacts can be re-resolved afterwards; you can disable this by specifying -DreResolve=false.
In its simplest form, the mojo can be called like this:
mvn dependency:purge-local-repository
To add the restriction that the org.apache.maven:maven-plugin-api artifact not be deleted, we can modify the command to this:
mvn dependency:purge-local-repository -Dexclude=org.apache.maven:maven-plugin-api
Note: The exclude parameter is a comma-delimited list of groupId:artifactId pairs. It has a corresponding List-based parameter - excludes - for convenient use inside the POM.
Another handy aspect of this mojo is the ability to wipe out artifacts at varying depths. These depths are:
At a minimum, this amounts to file.getParentFile().getParentFile().getParentFile(). However, if the groupId contains multiple parts, the mojo will prune all groupId-part directories that contain only the files associated with this artifact. Again, note that the exception to this pruning algorithm is the lowest groupId part, which will always be pruned.
To prune dependency artifacts back to their associated artifactId directories (in order to verify proper artifact resolution, for example), simply use this command:
mvn dependency:purge-local-repository -DresolutionFuzziness=artifactId
Finally, it's possible to bind this mojo to the build lifecycle. One reason for this might be to clean out all dependencies when the build is initialized, to verify correct resolution.
Since: 2.0-alpha-2
This goal will output a classpath string of dependencies from the local repository to a file or log and optionally attach and deploy the file. For instance, the file would contain a classpath string like this:
/home/foo/.m2/repository/org/java/utils/util/util-1.0.jar:/home/foo/.m2/ ....
The resulting file could then be used like this:
java -cp `cat resultFile` MyClass
In its simplest form, to output the classpath to the log, the mojo can be called like this:
mvn dependency:build-classpath
or to write the classpath to cp.txt.:
mvn dependency:build-classpath -Dmdep.outputFile=cp.txt
The goal can also be bound to a lifecycle phase with the following configuration:
<project>
[...]
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.10</version>
<executions>
<execution>
<id>build-classpath</id>
<phase>generate-sources</phase>
<goals>
<goal>build-classpath</goal>
</goals>
<configuration>
<!-- configure the plugin here -->
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
[...]
</project>This mojo performs byte code analysis to determine missing or unused dependencies. This goal is meant to be launched from the command line. It will fork the build and execute test-compile so there are class files to analyze. If you want to bind analyze in your pom, use the dependency:analyze-only mojo instead.
This mojo can be executed from the command line:
mvn dependency:analyze
Sample output:
[INFO] [dependency:analyze] [WARNING] Used undeclared dependencies found: [WARNING] classworlds:classworlds:jar:1.1-alpha-2:compile [WARNING] org.apache.maven.shared:maven-invoker:jar:2.0.7-SNAPSHOT:test
This mojo looks at the dependencies after final resolution and looks for mismatches in your dependencyManagement section. In versions of maven prior to 2.0.6, it was possible to inherit versions that didn't match your dependencyManagement. See MNG-1577 for more info.
If this mojo detects issues, you should attempt to resolve the discrepancies before upgrading to 2.0.6 to avoid any surprises. This can be done by upgrading or downgrading the version in dependencyManagement to match what is actually being included at runtime, or you can specify a dependency in your project to override what is being included. You can check the results by rerunning this mojo. If you decide to override by using a dependency, be sure to note it so you can remove it later after upgrading to 2.0.6. You could also use the dependency:analyze mojo to uncover this unused direct dependency.
This mojo is also usefull for just detecting projects that override the dependencyManagement directly. Set ignoreDirect to false to detect these otherwise normal conditions.
This mojo can be executed from the command line:
mvn dependency:analyze-dep-mgt
Sample output:
[INFO] Found Resolved Dependency / DependencyManagement mismatches: [INFO] Dependency: commons-lang:commons-lang:jar [INFO] DepMgt : 1.0 [INFO] Resolved: 2.3 [INFO] Dependency: commons-digester:commons-digester:jar [INFO] DepMgt : 1.6 [INFO] Resolved: 1.7 [INFO] Dependency: javax.servlet:servlet-api:jar [INFO] DepMgt : 2.3 [INFO] Resolved: 2.4 [WARNING] Potential problems found in Dependency Management
This mojo is used to view the dependency hierarchy of the project currently being built. It will output the resolved tree of dependencies that the Maven build process actually uses.
This mojo can be executed from the command line:
mvn dependency:tree
Optionally, the output parameter can be specified to divert the output to a file:
mvn dependency:tree -Doutput=/path/to/file
Also, the outputType parameter can be used to generate different formats of output. The following formats are currently supported:
mvn dependency:tree -Doutput=/path/to/file.graphml -DoutputType=graphml
This mojo is used to list all the repositories that this build depends upon. It will show repositories defined in your settings, poms and declared in transitive dependency poms.
This mojo is used to fetch an artifact and (optionally) its dependencies from remote repositories using its Maven coordinates.
mvn dependency:get -DgroupId=org.apache.maven -DartifactId=maven-core -Dversion=2.2.1 -Dpackaging=jar -Dclassifier=sources -DremoteRepositories=central::default::http://repo1.maven.apache.org/maven2,myrepo::::http://myrepo.com/maven2 mvn dependency:get -DgroupId=org.apache.maven -DartifactId=maven-core -Dversion=2.2.1 -Dpackaging=jar -Dclassifier=sources -DremoteRepositories=http://repo1.maven.apache.org/maven2 mvn dependency:get -Dartifact=org.apache.maven:maven-core:2.2.1:jar:sources -DremoteRepositories=http://repo1.maven.apache.org/maven2 -Ddest=/tmp/myfile.jar
This mojo is used to include a report of the dependencies in the output of the maven-site-plugin.
<reporting>
<plugins>
...
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.5.1</version>
<reportSets>
<reportSet>
<reports>
<report>analyze-report</report>
</reports>
</reportSet>
</reportSets>
</plugin>
</plugins>
</reporting>