¿Cuál es la diferencia entre la dependencia de tipo "pom" con alcance "importación" y sin "importación"?


112

A partir de Maven 2.0.9 existe la posibilidad de incluir

<type>pom</type>
<scope>import</scope>

en la <dependencyManagement>sección.

Según tengo entendido, será "reemplazado" con las dependencias incluidas en este pom como si estuvieran definidas originalmente aquí.

¿Cuál es la diferencia entre la solución anterior y la simple dependencia a este pom sin importalcance (vi que este último se llama "agrupación de dependencias")? ¿Es la única diferencia que tales dependencias "agrupadas" tienen menor prioridad mientras resuelven la precedencia de las dependencias?

Respuestas:


187

Solo puede importar dependencias administradas . Esto significa que solo puede importar otros POM en la dependencyManagementsecció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 dependencyManagementsección del other-pom-artifact-idse incluyen en la dependencyManagementsección de su POM . Luego puede hacer referencia a estas dependencias en la dependencysección de su POM (y todos sus POM secundarios) sin tener que incluir un versionetc.

Sin embargo, si en su POM simplemente define una dependencia normal, other-pom-artifact-identonces todas las dependenciesde la dependencysección de other-pom-artifact-idse incluyen transitivamente en su proyecto; sin embargo, las dependencias definidas en la dependencyManagementsección de other-pom-artifact-idno 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 .


1
Si pomA en es padre de pomB, ¿puede colocar B en la gestión de dependencias del proyecto A con alcance import?
Janez Kuhar

gran respuesta para explicar cómo funciona, pero ¿por qué? ¿Por qué no quiere incluir las otras dependencias de forma transitiva? también puedes hacer ambas cosas? importar other-pom-artifact-id y luego declarar other-pom-artifact-id como dependencia también?
Junchen Liu

Un artículo sobre DZone dice algo diferente: ... <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 War
porque

1
@JunchenLiu: Digamos que está utilizando solo un par de características del proyecto A, por lo que puede elegir incluir solo las dependencias transitivas que se requieren para esa característica. Puede solucionarlo utilizando <exclude> en <dependencia> también. Por ejemplo, consulte
Nitiraj

15

No puede tener un pomproyecto de tipo como simple dependencyen otro proyecto. (Bueno, puede, pero no servirá de nada). Solo puede haber una parent-childrelación. Esto es esencialmente managing dependency through inheritance.

importel alcance de la pomdependencia de tipos en la <dependencyManagement>sección le permite lograr el equivalente de multiple inheritance.

Podría tener diferentes poms, cada managinguna un montón de dependencias relacionadas. Los proyectos que usan estos pueden importestos pomsy luego especificar las dependencias que necesitan sin necesidad de preocuparse por la versión. Este es esencialmente el bill of materialsconcepto, que se ilustra en los enlaces especificados por @ DB5.

Esto ayuda a evitar que parent pomslos proyectos complejos de varios módulos se vuelvan demasiado grandes y difíciles de manejar.


8
¿Estás seguro? Puse pom regular (que tiene sus propias dependencias) como una dependencia regular en otro proyecto (guerra de empaquetado) y obtuve todas las dependencias del proyecto pom incluidas en WEB-INF / lib del proyecto de destino. Por eso hago esta pregunta :)
grafthez

2
Gracias @Raghuram, me olvidé por completo de mencionar la opción POM principal al responder la pregunta. En cuanto a tener un proyecto tipo pom como dependencia simple, esto es posible. Como se mencionó en la pregunta original, se puede usar para agrupar dependencias
DB5


5

Dos conceptos, muy similares al paradigma de programación orientada a objetos, ayudarán a responder la pregunta:

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

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


Eso es bueno y claro, pero responde a una pregunta diferente a la anterior. :-)
Rick-777
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.