Author: rgoers
Date: Sun Sep 23 15:47:52 2007
New Revision: 578609
URL: http://svn.apache.org/viewvc?rev=578609&view=rev
Log:
Update documentation to reflect importing of managed dependencies
Modified:
maven/site/trunk/src/site/apt/guides/introduction/introduction-to-dependency-mechanism.apt
Modified:
maven/site/trunk/src/site/apt/guides/introduction/introduction-to-dependency-mechanism.apt
URL:
http://svn.apache.org/viewvc/maven/site/trunk/src/site/apt/guides/introduction/introduction-to-dependency-mechanism.apt?rev=578609&r1=578608&r2=578609&view=diff
==============================================================================
---
maven/site/trunk/src/site/apt/guides/introduction/introduction-to-dependency-mechanism.apt
(original)
+++
maven/site/trunk/src/site/apt/guides/introduction/introduction-to-dependency-mechanism.apt
Sun Sep 23 15:47:52 2007
@@ -70,7 +70,7 @@
Dependency scope is used to limit the transitivity of a depedency, and also
to affect the classpath used for
various build tasks.
- There are 5 scopes available:
+ There are 6 scopes available:
* <<compile>>
- this is the default scope, used if none is specified. Compile
dependencies are available
@@ -92,13 +92,18 @@
- this scope is similar to provided except that you have to provide the JAR
which contains it explicitly. The artifact is always available and is not
looked up in a repository.
+
+ * <<import>>
+ - this scope is only used on a dependency of type "pom" in the
dependencyManagement section. It indicates that the specified
+ pom should be replaced with the dependencies in that pom's
dependencyManagement section. Since they are replaced,
+ dependencies with a scope of import do not actually participate in
limiting the transitivity of a dependency.
[]
- Each of the scopes affects transitive dependencies in different ways, as is
demonstrated in the table below.
+ Each of the scopes (except for import) affects transitive dependencies in
different ways, as is demonstrated in the table below.
If a dependency is set to the scope in the left column, transitive
dependencies of that dependency with the
scope across the top row will result in a dependency in the main project with
the scope listed at the
- intersection. If no scope is listed, it means the dependency will be omitted.
+ intersection. If no scope is listed, it means the dependency will be omitted.
*----------+------------+----------+----------+------+
| | compile | provided | runtime | test
@@ -384,7 +389,160 @@
The reference information about the dependency management tags is available
from the
{{{../../ref/current/maven-model/maven.html#class_DependencyManagement}project
descriptor reference}}.
+** Importing Dependencies
+
+ <The features defined in this section are only available in maven 2.0.8 or
later.>
+
+ The examples in the previous section describe how to specify managed
dependencies through inheritence. However,
+ in larger projects it may be impossible to accomplish this since a project
can only inherit from a single parent.
+ To accomodate this, projects can import managed dependencies from other
projects. This is accomplished by declaring a
+ pom artifact as a dependency with a scope of "import".
+
+ Project B:
+
++----+
+
+<project>
+ <modelVersion>4.0.0</modelVersion>
+ <groupId>maven</groupId>
+ <artifactId>B</artifactId>
+ <packaging>pom</packaging>
+ <name>B</name>
+ <version>1.0</version>
+ <dependencyManagement>
+ <dependencies>
+ <dependency>
+ <groupId>maven</groupId>
+ <artifactId>A</artifactId>
+ <version>1.0</version>
+ <type>pom</type>
+ <scope>import</scope>
+ </dependency>
+ <dependency>
+ <groupId>test</groupId>
+ <artifactId>d</artifactId>
+ <version>1.0</version>
+ </dependency>
+ </dependencies>
+ </dependencyManagement>
+ <dependencies>
+ <dependency>
+ <groupId>maven-test</groupId>
+ <artifactId>a</artifactId>
+ <version>1.0</version>
+ <scope>runtime</scope>
+ </dependency>
+ <dependency>
+ <groupId>maven-test</groupId>
+ <artifactId>c</artifactId>
+ <scope>runtime</scope>
+ </dependency>
+ </dependencies>
+</project>
+
++----+
+
+ Assuming A is the pom defined in the preceding example, the end result would
be the same. All of A's managed dependencies
+ would be incorporated into B except for d since it is defined in this pom.
+
+ Project X:
+
++----+
+
+<project>
+ <modelVersion>4.0.0</modelVersion>
+ <groupId>maven</groupId>
+ <artifactId>X</artifactId>
+ <packaging>pom</packaging>
+ <name>X</name>
+ <version>1.0</version>
+ <dependencyManagement>
+ <dependencies>
+ <dependency>
+ <groupId>test</groupId>
+ <artifactId>a</artifactId>
+ <version>1.1</version>
+ </dependency>
+ <dependency>
+ <groupId>test</groupId>
+ <artifactId>b</artifactId>
+ <version>1.0</version>
+ <scope>compile</scope>
+ </dependency>
+ </dependencies>
+ </dependencyManagement>
+</project>
+
++----+
+
+ Project Y:
+
++----+
+
+<project>
+ <modelVersion>4.0.0</modelVersion>
+ <groupId>maven</groupId>
+ <artifactId>Y</artifactId>
+ <packaging>pom</packaging>
+ <name>Y</name>
+ <version>1.0</version>
+ <dependencyManagement>
+ <dependencies>
+ <dependency>
+ <groupId>test</groupId>
+ <artifactId>a</artifactId>
+ <version>1.2</version>
+ </dependency>
+ <dependency>
+ <groupId>test</groupId>
+ <artifactId>c</artifactId>
+ <version>1.0</version>
+ <scope>compile</scope>
+ </dependency>
+ </dependencies>
+ </dependencyManagement>
+</project>
+
++----+
+
+ Project Z:
+
++----+
+
+<project>
+ <modelVersion>4.0.0</modelVersion>
+ <groupId>maven</groupId>
+ <artifactId>Z</artifactId>
+ <packaging>pom</packaging>
+ <name>Z</name>
+ <version>1.0</version>
+ <dependencyManagement>
+ <dependencies>
+ <dependency>
+ <groupId>maven</groupId>
+ <artifactId>X</artifactId>
+ <version>1.0</version>
+ <type>pom</type>
+ <scope>import</scope>
+ </dependency>
+ <dependency>
+ <groupId>maven</groupId>
+ <artifactId>Y</artifactId>
+ <version>1.0</version>
+ <type>pom</type>
+ <scope>import</scope>
+ </dependency>
+ </dependencies>
+ </dependencyManagement>
+</project>
+
++----+
+
+ In the example above Z imports the managed dependencies from both X and Y.
However, both X and Y contain depedency a. Here,
+ version 1.1 of a would be used since X is declared first and a is not
declared in Z's dependencyManagement.
+ This process is recursive. For example, if X imports another pom, Q, when Z
is processed it will simply appear that all
+ of Q's managed dependencies are defined in X.
* System Dependencies
