Résolution de dépendance Maven et remplacement de la portée
Avertissement
(j'ai initialement posé la question de manière très détaillée ici . Je l'ai extrait ici car la liste de diffusion maven-users est restée silencieuse sur cette question.) (pas seulement une autre question de débutant)
Référence
Mon matériel de référence est http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management; veuillez me faire savoir dans cette discussion si cela est obsolète ou Faux.
Question
Il y a une section dans ce document qui commence par "une seconde, et très importante...". Dans ce qui suit, je vais me référer aux projets de cette section A et B, et en extraire.
Dans cet article, vous verrez que le projet A est un <dependencyManagement> section--entre autres--définit un artefact, c, comme ayant une portée 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>
, Puis vous verrez un pom.xml, pour le projet B (a) hérite de projet A (donc hériter de sa section dependencyManagement) et (b) établit une dépendance à l'artefact c, sans avoir à spécifier son version. Vous remarquerez également que la dépendance de l'artefact c remplace le champ d'application de c à runtime, pas 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>
Encore une fois, vous remarquerez qu'il n'y a pas d'élément <version>, mais il y a un élément <scope>runtime</scope>.
Mon interprétation de ce que, quand tout est dit et fait, B dépendra de la version de 1.0 de l'artefact c dans runtime portée, pas compile portée.
Est-ce exact? Mon maven-ear-plugin bug, repose sur le fait que c'est le comportement attendu. Ce n'est pas ce qui se passe lorsque le maven-ear-plugin construit un fichier .ear.
Ensuite, si c'est correct, je m'attendrais aussi à ce que si artefact c avait des dépendances transitives runtime, ils seraient disponibles dans runtime classpath de B (tel que défini par la table quelque peu déroutante dans http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope).
Est-ce exact?
1 réponses
En cours d'exécution mvn dependency:tree sur l'exemple de projet posté dans le lien de bogue spécifié ci-dessus,
[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
La dépendance scope de mear-143-leaf dans mear-143-middle, où la dépendance est explicitement définie est en effet runtime, remplaçant la portée test définie dans la section dependencyManagement du parent pom, mear-143.
Dans mear-143-ear, mear-143-leaf inclure transitivement. Ici, la portée test définie dans dependencyManagement de mear-143 a priorité sur la portée runtime héritée.
Ceci, je suppose est en ligne avec ce qui est spécifié dans le deuxième point de la section que vous avez mentionnée ci-dessus. Citant ici et mettant en évidence en gras et en italique les parties pertinentes:
B est défini dans la section de gestion des dépendances du parent de B et depuis la gestion des dépendances a préséance sur la médiation des dépendances pour les dépendances transitives , version 1.0 seront sélectionnées si elles sont référencé dans le pom de a ou c. b aura également une portée de compilation