What is the difference between "pom" type dependency with scope "import" and without "import"?

Question

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:

1. 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.

2. 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.