maven - homepage - pom.xml que es

Diferencias entre la gestión de dependencias y dependencias en Maven

Question

¿Cuál es la diferencia entre la dependencyManagement y las dependencies ? He visto los documentos en el sitio web de Apache Maven. Parece que una dependencia definida bajo la dependencyManagement se puede utilizar en sus módulos secundarios sin especificar la versión.

Por ejemplo:

Un proyecto padre (Pro-par) define una dependencia bajo dependencyManagement :

<dependencyManagement>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8</version>
</dependency>
</dependencies>
</dependencyManagement>

Luego, en el hijo de Pro-par, puedo usar el junit:

 <dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
</dependency>
</dependencies>

Sin embargo, me pregunto si es necesario definir junit en el pom principal. ¿Por qué no definirlo directamente en el módulo necesario?

Answer 1

En Eclipse, hay una característica más en la dependencyManagement . Cuando se utilizan las dependencies sin él, las dependencias no encontradas se notan en el archivo pom. Si se utiliza dependencyManagement , las dependencias no resueltas pasan inadvertidas en el archivo pom y los errores aparecen solo en los archivos java. (Importaciones y tal ...)

Answer 2

En el POM principal, la principal diferencia entre las <dependencies> y <dependencyManagement> es esta:

Los artefactos especificados en la sección <dependencies> SIEMPRE se incluirán como una dependencia de los módulos secundarios.

Los artefactos especificados en la sección solo se incluirán en el módulo secundario si también se especificaron en la sección del propio módulo secundario. ¿Por qué es bueno lo preguntas? porque especifica la versión y / o el alcance en el principal, y puede omitirlos al especificar las dependencias en el POM secundario. Esto puede ayudarlo a usar versiones unificadas para dependencias para módulos secundarios, sin especificar la versión en cada módulo secundario.

Answer 3

Es como dijiste; dependencyManagement se utiliza para reunir toda la información de dependencia en un archivo POM común, simplificando las referencias en el archivo POM secundario.

Se vuelve útil cuando tiene múltiples atributos que no desea volver a escribir en varios proyectos secundarios.

Finalmente, dependencyManagement se puede usar para definir una versión estándar de un artefacto para usar en múltiples proyectos.

Answer 4

Estoy retrasado con respecto a esta pregunta, pero creo que vale la pena dar una respuesta más clara que la aceptada (lo cual es correcto, pero no enfatiza la parte realmente importante, que debes deducir).

En el POM principal, la principal diferencia entre las <dependencies> y <dependencyManagement> es esta:

Los artefactos especificados en la sección <dependencies> SIEMPRE se incluirán como una dependencia de los módulos secundarios.

Los artefactos especificados en la sección <dependencyManagement> , solo se incluirán en el módulo secundario si también se especificaron en la sección <dependencies> del propio módulo secundario. ¿Por qué es bueno lo preguntas? porque especifica la versión y / o el alcance en el principal, y puede omitirlos al especificar las dependencias en el POM secundario. Esto puede ayudarlo a usar versiones unificadas para dependencias para módulos secundarios, sin especificar la versión en cada módulo secundario.

Answer 5

Hay algunas respuestas que <depedencies> diferencias entre las <depedencies> y <dependencyManagement> con maven.

Sin embargo, algunos puntos se explican a continuación de manera concisa:

1. <dependencyManagement> permite consolidar todas las dependencias (utilizadas a nivel de pom de niño) usadas en diferentes módulos: claridad , administración de versiones de dependencia central
2. <dependencyManagement> permite actualizar / degradar fácilmente las dependencias según la necesidad; en otro escenario, esto debe ejercerse en todos los niveles de pom del niño: coherencia
3. las dependencias proporcionadas en la etiqueta <dependencies> siempre se importan, mientras que las dependencias proporcionadas en <dependencyManagement> en el pom principal se importarán solo si pom secundario tiene una entrada respectiva en su etiqueta <dependencies> .

Answer 6

La documentación en el sitio de Maven es horrible. Lo que hace dependencyManagement es simplemente mover sus definiciones de dependencia (versión, exclusiones, etc.) al pom principal, luego en los poms secundarios solo tiene que colocar groupId y artifactId. Eso es todo (excepto por el encadenamiento de pom padre y similares, pero eso tampoco es realmente complicado: la administración de dependencias gana sobre las dependencias a nivel de padres), pero si tiene una pregunta sobre eso o importa, la documentación de Maven es un poco mejor).

Después de leer toda la basura ''a'', ''b'', ''c'' en el sitio de Maven y confundirme, reescribí su ejemplo. Por lo tanto, si tiene 2 proyectos (proj1 y proj2) que comparten una dependencia común (betaShared), podría mover esa dependencia hasta el pom principal. Mientras lo hace, también puede subir cualquier otra dependencia (alfa y charlie) pero solo si tiene sentido para su proyecto. Entonces, para la situación descrita en las oraciones anteriores, aquí está la solución con dependencyManagement en el pom principal:

<!-- ParentProj pom -->
<project>
<dependencyManagement>
<dependencies>
<dependency> <!-- not much benefit defining alpha here, as we only use in 1 child, so optional -->
<groupId>alpha</groupId>
<artifactId>alpha</artifactId>
<version>1.0</version>
<exclusions>
<exclusion>
<groupId>zebra</groupId>
<artifactId>zebra</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>charlie</groupId> <!-- not much benefit defining charlie here, so optional -->
<artifactId>charlie</artifactId>
<version>1.0</version>
<type>war</type>
<scope>runtime</scope>
</dependency>
<dependency> <!-- defining betaShared here makes a lot of sense -->
<groupId>betaShared</groupId>
<artifactId>betaShared</artifactId>
<version>1.0</version>
<type>bar</type>
<scope>runtime</scope>
</dependency>
</dependencies>
</dependencyManagement>
</project>
<!-- Child Proj1 pom -->
<project>
<dependencies>
<dependency>
<groupId>alpha</groupId>
<artifactId>alpha</artifactId> <!-- jar type IS DEFAULT, so no need to specify in child projects -->
</dependency>
<dependency>
<groupId>betaShared</groupId>
<artifactId>betaShared</artifactId>
<type>bar</type> <!-- This is not a jar dependency, so we must specify type. -->
</dependency>
</dependencies>
</project>
<!-- Child Proj2 -->
<project>
<dependencies>
<dependency>
<groupId>charlie</groupId>
<artifactId>charlie</artifactId>
<type>war</type> <!-- This is not a jar dependency, so we must specify type. -->
</dependency>
<dependency>
<groupId>betaShared</groupId>
<artifactId>betaShared</artifactId>
<type>bar</type> <!-- This is not a jar dependency, so we must specify type. -->
</dependency>
</dependencies>
</project>

Answer 7

Si la dependencia se definió en el elemento dependencyManagement del pom de nivel superior, el proyecto hijo no tuvo que listar explícitamente la versión de la dependencia. si el proyecto hijo definiera una versión, se anularía la versión que se encuentra en la sección de gestión de dependencias de POM de nivel superior. Es decir, la versión dependencyManagement solo se usa cuando el hijo no declara una versión directamente.

Answer 8

Todavía hay una cosa que no está lo suficientemente resaltada, en mi opinión, y es la herencia no deseada .

Aquí hay un ejemplo incremental:

Yo declaro en mi parent pom:

<dependencies>
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>19.0</version>
</dependency>
</dependencies>

¡auge! Lo tengo en mis módulos Child A , Child B y Child C :

• Implicabilidad heredada por los niños poms.
• Un solo lugar para gestionar.
• No hay necesidad de redeclar nada en poms infantiles.
• Todavía puedo volver a cuidar y anular la version 18.0 en un Child B si quiero.

Pero, ¿y si termino no necesitando guayaba en el Child C y tampoco en los futuros módulos del Child D y el Child E ?

¡Todavía lo heredarán y esto no es deseado! Esto es como el olor del código Java God Object, donde se heredan algunos bits útiles de una clase y también un montón de cosas no deseadas.

Aquí es donde <dependencyManagement> entra en juego. Cuando agrega esto a su padre pom, todos sus módulos hijos DEJEN de verlo . Y, por lo tanto, se ve obligado a ingresar a cada módulo individual que SÍ lo necesite y lo declare nuevamente ( Child A y Child B , sin embargo, sin la versión).

Y, obviamente, no lo haces para el Child C , y por lo tanto tu módulo sigue siendo magro.

Answer 9

La administración de dependencias permite consolidar y centralizar la administración de las versiones de dependencia sin agregar dependencias heredadas por todos los hijos. Esto es especialmente útil cuando tiene un conjunto de proyectos (es decir, más de uno) que hereda un padre común.

Otro caso de uso extremadamente importante de la administración de dependencyManagement es el control de versiones de artefactos utilizados en dependencias transitivas. Esto es difícil de explicar sin un ejemplo. Afortunadamente, esto se ilustra en la documentación.