Starting from Maven 2.0.9 there is possibility to include
<type>pom</type>
<scope>import</scope>
in the <dependencyManagement>
section.
As I understand it, it will be "replaced" with dependencies included in this pom as if they were originally defined here.
What is the difference between solution above and simple dependency to this pom without import
scope (I saw the latter being called "dependencies grouping")? Is the only difference that such "grouped" dependencies have lower priority while resolving dependencies precedence?
You can only import managed dependencies. This means you can only import other POMs into the dependencyManagement
section of your project's POM. i.e.
...
<dependencyManagement>
<dependencies>
<dependency>
<groupId>other.pom.group.id</groupId>
<artifactId>other-pom-artifact-id</artifactId>
<version>SNAPSHOT</version>
<scope>import</scope>
<type>pom</type>
</dependency>
</dependencies>
</dependencyManagement>
...
What then happens is that all the dependencies defined in the dependencyManagement
section of the other-pom-artifact-id
are included in your POM's dependencyManagement
section. You can then reference these dependencies in the dependency
section of your POM (and all of its child POMs) without having to include a version
etc.
However if in your POM you simply define a normal dependency to other-pom-artifact-id
then all dependencies
from the dependency
section of the other-pom-artifact-id
are included transitively in your project - however the dependencies defined in the dependencyManagement
section of the other-pom-artifact-id
are not included at all.
So basically the two different mechanisms are used for importing/including the two different types of dependencies (managed dependencies and normal dependencies).
There is a good page on the maven website, which can explain this far better than I can, Dependency Management in Maven and it also contains specific information on importing dependencies.
You cannot have a pom
type project as a simple dependency
in another project. (Well, you can - but it will not do anything useful). There can only be a parent-child
relationship. This is essentially managing dependency through inheritance
.
import
scope for pom
type dependency in <dependencyManagement>
section allows you to achieve the equivalent of multiple inheritance
.
You could have different poms
- each managing
a bunch of related dependencies. The projects which use these could import
these poms
and then specify the dependencies that they need without needing to worry about the version. This is essentially the bill of materials
concept, which is illustrated in the links specified by @DB5.
This helps to keep parent poms
of complex multi-module projects from getting too large and unwieldy.
Two concepts, very much similar to object-oriented programming paradigm, will help to answer the question:
The dependencyManagement section only declares the dependencies and their details in the current project - the purpose is management of the details and re-use in other projects, either via inheritance (parent) or import (scope). This is like declaring a data type in program and make it available for use.
The dependency section defines the actual use of the dependencies in the project, optionally inherit the details (i.e., version, etc.) of the dependencies declared under the dependencyManagment. That's why you will have missing dependencies if you only put them in dependencyManagment. This is analogous to instantiating an variable instance of a data type in a program where it is needed.