Maven Concepts - Dependencies

External

• Introduction to the Dependency Mechanism https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

Internal

• Maven Concepts

Dependency Operations

Maven dependency Plugin Operations

Transitive Dependencies

Maven walks the dependency graph of your direct dependencies, allowing you to avoid the need to discover and specify those libraries by hand. This is possible because Maven reads the project files of the dependencies, recursively, from their repositories. There is no limit on the number of recursive levels Maven can walk.

Since the transitive dependency graph can grow pretty large, Maven offer a series of features that can be used to limit and manage the extent of the graph (dependency mediation, dependency management, dependency scope, excluded dependencies, optional dependencies).

The transitivity is interrupted when a dependency is declared <provided>.

Dependency Mediation

Dependency mediation is used when multiple version of the same artifact are found while building the transitive graph.

The default mediation mechanism is "nearest definition", where the "closest" dependency in the graph dictates the version. However, a certain (different) version can be guaranteed by declaring it explicitly in the dependency management section of the POM.

If two dependency versions are at the same depth, the declaration order counts: the first declaration wins.

Dependency Scope

The dependency scope is a declarative feature that allows you to only include dependencies appropriate for the current stage of the build. There are 6 scopes:

compile

The default scope, when none is specified. Compile dependencies are available in all classpaths of the project and propagated to dependent projects.

provided

Makes the dependencies available on the compilation and test class path, but does not includes the dependencies in the artifacts - because "provided" dependencies are assumed to be provided by the deployment environment.

The provided scope is not transitive, meaning that once a dependency was declared <provided>, its dependencies won't be transitively added to the classpath.

runtime

Places the dependencies in the runtime and test classpaths, but not in the compile classpath.

test

This scope indicates that the dependency is not required for normal use of the application. The dependency is placed on the test compilation and test execution classpaths.

system

Similar with "provided", except that the dependency artifact must be specified in the POM - it is not looked up in a repository:

     ...
    <dependency>
        <groupId>javax.sql</groupId> 
        <artifactId>jdbc-stdext</artifactId>
        <version>2.0</version>
        <scope>system</scope> 
        <systemPath>${java.home}/lib/rt.jar</systemPath>
    </dependency> 

    ...

    <dependency>
        <groupId>sample</groupId>
        <artifactId>com.sample</artifactId>
        <version>1.0</version>
        <scope>system</scope>
        <systemPath>${project.basedir}/src/main/resources/yourJar.jar</systemPath>
    </dependency>
    ...

import

This scope is only used with a dependency of the type "pom" in <dependencyManagement> section. The effect is inclusion of the dependencies specified in the POM's <dependencyManagement> section. This is used to implement the Bill of Materials (BOM) pattern. Since they are replaced, dependencies with a scope of "import" do not participate in limiting the transitivity of a dependency.

How Scopes Affect Transitivity

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. No scope listed means the dependency will be omitted:

	compile	provided	runtime	test
compile	compile	-	runtime	-
provided	provided	-	provided	-
runtime	runtime	-	runtime	-
test	test	-	test	-

Dependency Management

If project POMs are declared hierarchically, a useful feature is dependency management, that allows dependency information inheritance amongst hierarchical projects. The dependency management is a Maven feature that provide the following functions:

1. It allows for the centralization of the dependency information. The dependency management can be used to specify versions for dependencies whose version were not specified directly in the <dependencies> section.

2. Dependency information inheritance. When you have a set of projects that inherit a common parent you can put all the information about the dependencies in the <dependencyManagement> section of the common POM and have simpler references to artifacts in child POMs. If a dependency is incompletely declared in a child pom and it is not present in the parent's <dependencyManagement> section, the build will fail.

3. It allows project authors to declare specific versions for their dependencies, when those dependencies are encountered in the transitive dependency graph (you can see it as a mask that applies to the transitive dependency graph).

Configuration:

<dependencyManagement>

Excluded Dependencies

Dependencies that are pulled in with the transitive dependency graph can be explicitly excluded with the <exclusion> element.

Optional Dependencies

Optional dependencies do are not included in the transitive dependency graph. Optional means "excluded by default".

BOM

BOM (Bill of Material) is a pattern that allow projects to import managed dependencies from another project.

This is accomplished by declaring a "pom" artifact as a dependency with the "import" scope. This provides the equivalent of a "bill of materials". The bill of materials is essentially a versioned list of dependencies.

Using a BOM

A project ("bom") can declare itself a "bill of materials" and it defines the versions of the artifacts that will be created in the library of artifacts. This effectively incapsulates a set of versions and gives a unique version to the incapsulated list. The BOMs are usually assembled by vendors. An example of vendor-assembled BOMs are the JBoss EAP BOMs.

<project ...>
  <groupId>com.test</groupId>
  <artifactId>bom</artifactId>
  <version>1.0.0</version>
  <packaging>pom</packaging>
  <properties>
    <project1Version>1.0.0</project1Version>
    <project2Version>1.0.0</project2Version>
  </properties>
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>com.test</groupId>
        <artifactId>project1</artifactId>
        <version>${project1Version}</version>
      </dependency>
      <dependency>
        <groupId>com.test</groupId>
        <artifactId>project2</artifactId>
        <version>${project1Version}</version>
      </dependency>
    </dependencies>
  </dependencyManagement>
</project>

The project that relies on one or more specific dependencies declared in the BOM can import the BOM, thus introducing the dependency graph declared by the BOM into its own dependency resolution

Other project (X) can import it, thus importing all dependencies declared in the bill of material.

Also see import scope.

"bom" POM:

X POM:

<project ...>
  <groupId>X</groupId>
  <artifactId>x</artifactId>
  <version>1.0</version>
  <packaging>jar</packaging>
 
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>com.test</groupId>
        <artifactId>bom</artifactId>
        <version>1.0.0</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>com.test</groupId>
      <artifactId>project1</artifactId>
    </dependency>
    <dependency>
      <groupId>com.test</groupId>
      <artifactId>project2</artifactId>
    </dependency>
  </dependencies>
</project>

A BOM specifies a dependency graph to chose from, not a dependency. The dependencies still need to be declared, but with a BOM, Maven will prioritize artifacts specified by the BOM over other artifacts, when resolving transitive dependencies.

TODO: Experiment with it.

Related:

JBoss EAP BOMs