From 16bbbbdd9102f2e9c6835a22087c71a774915523 Mon Sep 17 00:00:00 2001 From: Trygve Laugstol Date: Tue, 9 Aug 2005 00:20:31 +0000 Subject: [PATCH] o Adding a piece about dependency management. git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@230934 13f79535-47bb-0310-9956-ffa450edef68 --- .../src/site/xdoc/dependency-mechanism.xml | 167 ++++++++++++++++-- 1 file changed, 157 insertions(+), 10 deletions(-) diff --git a/maven-site/src/site/xdoc/dependency-mechanism.xml b/maven-site/src/site/xdoc/dependency-mechanism.xml index 38f5241710..44f73a7631 100644 --- a/maven-site/src/site/xdoc/dependency-mechanism.xml +++ b/maven-site/src/site/xdoc/dependency-mechanism.xml @@ -2,16 +2,29 @@ Dependency Mechanism Brett Porter + Trygve Laugstol

There are many aspects to working with dependencies in Maven. While it is not the sole focus of Maven, it - does comprise a large and important part of the system. + does comprise a large and important part of the system. Learn more about: +

- This document is currently in the process of being written, so not all facets are covered. + This document is currently in the process of being written, so not all facets are covered.

+

Transitive dependencies are a new feature in Maven 2.0. This allows you to avoid needing to discover and @@ -33,12 +46,14 @@

  • - Dependency mediation- this determines what version of a dependency will be used when multiple + Dependency mediation + - this determines what version of a dependency will be used when multiple different ones are encountered. Currently, Maven 2.0 only supports using the "nearest definition" - so you can always guarantee a version by declaring it explicitly in the project's POM.
  • - Dependency scope- this allows you to only include dependencies appropriate for the current stage + Dependency scope + - this allows you to only include dependencies appropriate for the current stage of the build. This is described in more detail below.
@@ -49,6 +64,7 @@

+

Dependency scope is used to limit the transitivity of a depedency, and also to affect the classpath used for various build tasks. @@ -58,20 +74,24 @@

  • - compile- this is the default scope, used if none is specified. Compile dependencies are available + compile + - this is the default scope, used if none is specified. Compile dependencies are available in all classpaths.
  • - provided- this is much like compile, but indicates you expect the JDK or a container to provide it. + provided + - this is much like compile, but indicates you expect the JDK or a container to provide it. It is only available on the compilation classpath, and is not transitive.
  • - runtime- this scope indicates that the dependency is not required for compilation, but is for + runtime + - this scope indicates that the dependency is not required for compilation, but is for execution. It is in the runtime and test classpaths, but not the compile classpath.
  • - test- this scope indicates that the dependency is not required for normal use of the application, and + test + - this scope indicates that the dependency is not required for normal use of the application, and is only available for the test compilation and execution phases.
@@ -119,13 +139,140 @@

- (*) Note:it is intended that this should be runtime instead, so that all compile dependencies must + (*) Note: + it is intended that this should be runtime instead, so that all compile dependencies must be explicitly listed - however, there is the case where the library you depend on extends a class from another library, forcing you to have available at compile time. For this reason, compile time dependencies remain as compile scope even when they are transitive.

+ + +

+ The dependency management section is a mechanism for centralizing dependency information. When you have + a set of projects that inherits a common parent it's possible to put all information about the dependency + in the common POM and have simpler references to the artifacts in the child POMs. The mechanism is best + illustrated through some examples. Given these two POMs which extend the same parent: +

+

+ Project A: + + ... + + + group-a + artifact-a + 1.0 + + + group-c + excluded-artifact + + + + + group-a + artifact-b + 1.0 + bar + runtime + + +]]> + Project B: + + ... + + + group-c + artifact-b + 1.0 + war + runtime + + + group-a + artifact-b + 1.0 + bar + runtime + + +]]> +

+

+ These two example POMs share a common dependencies and each one non-trivial dependency. This information + can be put in the parent POM like this: + + ... + + + group-a + artifact-a + 1.0 + + + group-c + excluded-artifact + + + + + group-c + artifact-b + 1.0 + war + runtime + + + group-a + artifact-b + 1.0 + bar + runtime + + +]]> + And then the two child poms would become much simpler: +

+

+ + ... + + + group-a + artifact-a + + + group-a + artifact-b + + +]]> + + ... + + + group-c + artifact-b + + + group-a + artifact-b + + +]]> +

+

+ The reference information about the dependency management tags is available from the + project descriptor reference. +

+
-