plugin exclude example dependency maven dependency-management maven-ear-plugin

exclude - maven repository



Resolución de dependencias de Maven y anulación de alcance (1)

Renuncia

(Originalmente hice la pregunta de una manera muy detallada aquí . La he extractado aquí porque la lista de correo de maven-users se ha silenciado en esta pregunta.) (No es solo otra pregunta para novatos)

Referencia

Mi material de referencia es http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management ; por favor, hágamelo saber en esta discusión si esto está desactualizado o es incorrecto.

Pregunta

Hay una sección en ese documento que comienza con "Un segundo, y muy importante ...". En lo que sigue me referiré a los proyectos A y B esa sección, y los sacaré de ellos.

En esa sección, verá que el proyecto A tiene una sección <dependencyManagement> que, entre otras cosas, define un artefacto, c , que tiene alcance compile :

<!-- In A''s pom.xml; condensed for brevity --> <dependencyManagement> <dependency> <groupId>test</groupId> <artifactId>c</artifactId> <version>1.0</version> <scope>compile</scope> <!-- look: compile scope --> </dependency> </dependencyManagement>

Luego verá un pom.xml para el proyecto B que (a) hereda del proyecto A (heredando así su sección de gestión de dependencyManagement ) y (b) establece una dependencia en el artefacto c , sin tener que especificar su version . También notará que la dependencia en el artefacto c invalida el alcance de c para que sea runtime , no compile :

<!-- In B''s pom.xml, whose parent is A''s pom.xml (above); condensed for brevity --> <dependencies> <dependency> <groupId>test</groupId> <artifactId>c</artifactId> <scope>runtime</scope> <!-- look: runtime scope --> </dependency> </dependencies>

De nuevo, notará que no hay ningún elemento <version> , pero hay un elemento <scope>runtime</scope> .

Mi interpretación de esto es que cuando todo esté dicho y hecho, B dependerá de la versión 1.0 del artefacto c en el alcance del runtime de runtime , no del alcance de la compile .

¿Es eso correcto? Mi error maven-ear-plugin basa en el hecho de que este es el comportamiento esperado. No es lo que sucede cuando maven-ear-plugin construye un archivo .ear .

A continuación, si eso es correcto, también esperaría que si el artefacto c tuviera dependencias transitivas de runtime estaría disponible en el classpath en runtime B (como lo define la tabla un tanto desconcertante en http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope ).

¿Es eso correcto?

Ejecución de la mvn dependency:tree en el proyecto de muestra publicado en el enlace de error especificado anteriormente,

[INFO] Building MEAR-143 1.0-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] [INFO] --- maven-dependency-plugin:2.3:tree (default-cli) @ mear-143 --- [INFO] ljnelson:mear-143:pom:1.0-SNAPSHOT [INFO] /- junit:junit:jar:4.8.2:test [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building MEAR-143 Leaf 1.0-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] [INFO] --- maven-dependency-plugin:2.3:tree (default-cli) @ mear-143-leaf --- [INFO] ljnelson:mear-143-leaf:jar:1.0-SNAPSHOT [INFO] /- junit:junit:jar:4.8.2:test [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building MEAR-143 Middle 1.0-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] [INFO] --- maven-dependency-plugin:2.3:tree (default-cli) @ mear-143-middle --- [INFO] ljnelson:mear-143-middle:jar:1.0-SNAPSHOT [INFO] +- ljnelson:mear-143-leaf:jar:1.0-SNAPSHOT:runtime [INFO] /- junit:junit:jar:4.8.2:test [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building MEAR-143 EAR 1.0-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] [INFO] --- maven-dependency-plugin:2.3:tree (default-cli) @ mear-143-ear --- [INFO] ljnelson:mear-143-ear:ear:1.0-SNAPSHOT [INFO] +- ljnelson:mear-143-middle:jar:1.0-SNAPSHOT:runtime [INFO] | /- ljnelson:mear-143-leaf:jar:1.0-SNAPSHOT:test (scope managed from ru ntime) [INFO] /- junit:junit:jar:4.8.2:test

El scope de dependencia de mear-143-leaf en mear-143-middle , donde la dependencia se define explícitamente es en realidad el runtime , anulando el ámbito de test definido en la sección de mear-143 dependencyManagement de parent pom, mear-143 .

En mear-143-ear , mear-143-leaf se incluye transitivamente . En este caso, el alcance de test definido en dependencyManagement de mear-143 tiene prioridad sobre el alcance de runtime heredado.

Esto, supongo que está en línea con lo que se especifica en el segundo punto de la sección que ha mencionado anteriormente. Citarlo aquí y resaltar en negrita y cursiva las partes relevantes:

b se define en la sección de gestión de dependencias del padre de B y dado que la gestión de la dependencia tiene prioridad sobre la mediación de dependencia para las dependencias transitivas , se seleccionará la versión 1.0 si se hace referencia en el pom de a o c. b también tendrá alcance de compilación