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?

31
demandé sur ROMANIA_engineer 2011-09-28 23:27:10

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

24
répondu Raghuram 2011-09-29 12:52:03