Discussion :

[jpclavery]

Bonjour,

dans un pom j'ai deux versions différentes d'une librairie possédant le même groupId et artifactId :

[...]
<dependencies>
<dependency>
<groupId>jaxen-full</groupId>
<artifactId>jaxen-full</artifactId>
<version>1.0-cut</version>
</dependency>
<dependency>
<groupId>jaxen-full</groupId>
<artifactId>jaxen-full</artifactId>
<version>1.0-FCS</version>
</dependency>
</dependencies>
[..]

lors du téléchargement de ces librairies depuis le repository central de l'entreprise, qu'un seul des deux est téléchargé comme si maven se basé uniquement sur le groupId et l'artifactId et non le numéro de version.

Comment puis-je éviter cela ?

Merci par avance.

[romaintaz]

Il peut arriver qu'une librairie soit présente dans le pom.xml dans 2 versions différentes, surtout quand on considère les dépendances transitives. Par exemple, si moi j'utilise log4j, et que j'utilise d'autres librairies, il est très possible que l'une d'elle utilise aussi log4j.
Lorsque les 2 (ou plus) librairies ont la même version, alors pas de problème. Sinon, Maven va déterminer quelle version doit être conservée (souvent, ce sera la plus récente). J'avoue ne pas connaître les critères exacts utilisé par Maven pour faire ce choix. Mais de toutes façons, il est toujours préférable de ne pas avoir 2 fois une librairie dans ses dépendances, avec 2 versions différentes. Surtout si ce sont des dépendances directes.


Dans ton cas, il semblerait que tu déclares toi même ces dépendances. Quel est l'intérêt d'avoir les 2 versions au juste ?
Autre chose, quand tu dis "comment éviter cela", que souhaites tu éviter au juste ?

[jpclavery]

Merci pour ta r&#233;ponse. Je suis tout &#224; fait d'accord avec ton explication.
Dans mon cas, je passe sous maven 2 une application existante de type weblogic portal 8. Mon but est de construire un ear de fa&#231;on identique &#224; ce qu'il &#233;tait avant le passage sous maven 2 de l'application. A la base cette application ne semble pas avoir &#233;t&#233; bien construite et on se retrouve avec 2 versions diff&#233;rentes de log4j : un dans une webapp et l'autre au niveau de l'ear. Voil&#224; pourquoi je d&#233;clare les deux version de log4j dans mon pom.

Il peut arriver qu'une librairie soit présente dans le pom.xml dans 2 versions différentes, surtout quand on considère les dépendances transitives. Par exemple, si moi j'utilise log4j, et que j'utilise d'autres librairies, il est très possible que l'une d'elle utilise aussi log4j.
Lorsque les 2 (ou plus) librairies ont la même version, alors pas de problème. Sinon, Maven va déterminer quelle version doit être conservée (souvent, ce sera la plus récente). J'avoue ne pas connaître les critères exacts utilisé par Maven pour faire ce choix. Mais de toutes façons, il est toujours préférable de ne pas avoir 2 fois une librairie dans ses dépendances, avec 2 versions différentes. Surtout si ce sont des dépendances directes.


Dans ton cas, il semblerait que tu déclares toi même ces dépendances. Quel est l'intérêt d'avoir les 2 versions au juste ?
Autre chose, quand tu dis "comment éviter cela", que souhaites tu éviter au juste ?

[ehsavoie]

Le choix de la librairie se fait en prenant la plus proche dans l'arbre des dépendances :
ainsi si on a :
A
\_B
\_C 1.1
D
\_C 1.0
alors ça sera C 1.0 et non C1.1 qui sera choisie.
Cependant il reste un "magical effect" lorsque les deux dépendances sont au même niveau car c'est la première trouvée qui sera alors utilisée.

[romaintaz]

Le choix de la librairie se fait en prenant la plus proche dans l'arbre des dépendances :
ainsi si on a :
A
\_B
\_C 1.1
D
\_C 1.0
alors ça sera C 1.0 et non C1.1 qui sera choisie.
Cependant il reste un "magical effect" lorsque les deux dépendances sont au même niveau car c'est la première trouvée qui sera alors utilisée.

En effet :

"Dependency mediation - this determines what version of a dependency will be used when multiple versions of an artifact are encountered. Currently, Maven 2.0 only supports using the "nearest definition" which means that it will use the version of the closest dependency to your project in the tree of dependencies. You can always guarantee a version by declaring it explicitly in your project's POM. Note that if two dependency versions are at the same depth in the dependency tree, until Maven 2.0.4 it was not defined which one would win, but since Maven 2.0.5 it's the order in the declaration that counts: the first declaration wins.

"nearest definition" means that the version used will be the closest one to your project in the tree of dependencies, eg. if dependencies for A, B, and C are defined as A -> B -> C -> D 2.0 and A -> E -> D 1.0, then D 1.0 will be used when building A because the path from A to D through E is shorter. You could explicitly add a dependency to D 2.0 in A to force the use of D 2.0."

Source

[romaintaz]

Oki.
Quand on migre un projet vers Maven, c'est toujours l'occasion rêvée de faire le nettoyage dans les dépendances, voir ce qui est inutile, voir ce qui manque ou qui peut être évolué...