What is the difference between dependencies like "import" and "pom"?
Starting with Maven 2.0.9 it is possible to enable
<type>pom</type> <scope>import</scope> in the <dependencyManagement> section.
As I understand it, it will be "replaced" by the dependencies included in this pom, as if they were originally defined here.
What is the difference between the above solution and a simple dependency on this pom without import scope (I saw that the latter is called “dependency grouping”)? The only difference is that such “grouped” dependencies have a lower priority when resolving dependency priorities?
You can import only managed dependencies. This means that you can only import other POMs into the dependencyManagement section of your POM project. 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 happens is that all the dependencies defined in the dependencyManagement other-pom-artifact-id section are included in your POM dependencyManagement section. You can then reference these dependencies in the dependency section of your POM (and all its child POMs) without the need to include version , etc.
However, if in your POM you simply define a normal dependency on other-pom-artifact-id , then all the dependencies from the dependency other-pom-artifact-id section are transitively included in your project, however the dependencies defined in the dependencyManagement section are other-pom-artifact-id does not turn on at all.
Thus, basically two different mechanisms are used to import / enable two different types of dependencies (managed dependencies and normal dependencies).
The maven website has a nice page that can explain this much better than I can, Dependency Management in Maven , and also contains specific information about importing dependencies .
You cannot have a project like pom as a simple dependency in another project. (Well, you can - but nothing helps). A relationship can only be parent-child . This is essentially managing dependency through inheritance .
import region for pom type dependencies in the <dependencyManagement> section allows you to achieve the equivalent of multiple inheritance .
You may have a different poms - each managing set of related dependencies. Projects that use them can import these poms , and then specify the dependencies that they need without worrying about the version. This is essentially the concept of bill of materials , which is illustrated by the links given in @ DB5.
This helps keep the parent poms complex multi-module projects from being too large and bulky.
Two concepts that are very similar to the object-oriented programming paradigm will help answer the question:
The dependencyManagement section only declares dependencies and their data in the current project - the goal is to manage parts and reuse in other projects either through inheritance ( parent ) or import ( scope ). This is similar to declaring a data type in a program and making it available for use.
The dependency section defines the actual use of dependencies in the project; it does not necessarily inherit the details (i.e., version, etc.) of the dependencies declared in dependencyManagment . This is why you will have missing dependencies if you put them only in dependencyManagment . This is similar to creating an instance of a data type variable in a program where necessary.