Solo puede importar dependencias administradas . Esto significa que solo puede importar otros POM en la dependencyManagement
sección del POM de su proyecto. es decir
...
<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>
...
Lo que sucede entonces es que todas las dependencias definidas en la dependencyManagement
sección del other-pom-artifact-id
se incluyen en la dependencyManagement
sección de su POM . Luego puede hacer referencia a estas dependencias en la dependency
sección de su POM (y todos sus POM secundarios) sin tener que incluir un version
etc.
Sin embargo, si en su POM simplemente define una dependencia normal, other-pom-artifact-id
entonces todas las dependencies
de la dependency
sección de other-pom-artifact-id
se incluyen transitivamente en su proyecto; sin embargo, las dependencias definidas en la dependencyManagement
sección de other-pom-artifact-id
no se incluyen en absoluto.
Entonces, básicamente, los dos mecanismos diferentes se utilizan para importar / incluir los dos tipos diferentes de dependencias (dependencias administradas y dependencias normales).
Hay una buena página en el sitio web de Maven , que puede explicar esto mucho mejor que yo, Gestión de dependencias en Maven y también contiene información específica sobre la importación de dependencias .
pom
A en es padre depom
B, ¿puede colocar B en la gestión de dependencias del proyecto A con alcanceimport
?... <dependencies> <dependency> <groupId>${project.groupId}</groupId> <artifactId>pomlib-lib</artifactId> <type>pom</type> <scope>import</scope> </dependency> <dependency> <groupId>${project.groupId}</groupId> <artifactId>pomlib-war</artifactId> <type>war</type> </dependency> </dependencies> </project>
DRY y Skinny WarNo puede tener un
pom
proyecto de tipo comosimple dependency
en otro proyecto. (Bueno, puede, pero no servirá de nada). Solo puede haber unaparent-child
relación. Esto es esencialmentemanaging dependency through inheritance
.import
el alcance de lapom
dependencia de tipos en la<dependencyManagement>
sección le permite lograr el equivalente demultiple inheritance
.Podría tener diferentes
poms
, cadamanaging
una un montón de dependencias relacionadas. Los proyectos que usan estos puedenimport
estospoms
y luego especificar las dependencias que necesitan sin necesidad de preocuparse por la versión. Este es esencialmente elbill of materials
concepto, que se ilustra en los enlaces especificados por @ DB5.Esto ayuda a evitar que
parent poms
los proyectos complejos de varios módulos se vuelvan demasiado grandes y difíciles de manejar.fuente
Dos conceptos, muy similares al paradigma de programación orientada a objetos, ayudarán a responder la pregunta:
La sección de dependencyManagement solo declara las dependencias y sus detalles en el proyecto actual; el propósito es la administración de los detalles y la reutilización en otros proyectos, ya sea por herencia ( padre ) o importación ( alcance ). Esto es como declarar un tipo de datos en un programa y ponerlo a disposición para su uso.
La sección de dependencia define el uso real de las dependencias en el proyecto, opcionalmente hereda los detalles (es decir, la versión, etc.) de las dependencias declaradas bajo el dependencyManagment . Es por eso que le faltarán dependencias si solo las pone en dependencyManagment . Esto es análogo a instanciar una instancia variable de un tipo de datos en un programa donde se necesita.
fuente