web-dev-qa-db-fra.com

Interprétation de «omis pour conflit» dans l'arbre de dépendances de maven 2

Il s'agit d'un arbre de dépendances généré par Maven 2.2.1 avec mvn -o dependency:tree -Dverbose -Dincludes=log4j

[INFO] [dependency:tree {execution: default-cli}]
[INFO] com.openboxes.renderingservice:common:jar:1.0
[INFO] +- org.springframework:spring:jar:2.0.4:compile
[INFO] |  \- commons-logging:commons-logging:jar:1.1:compile
[INFO] |     \- log4j:log4j:jar:1.2.12:compile
[INFO] \- it.mycompany.portal:server:jar:1.5-SNAPSHOT:compile
[INFO]    \- org.slf4j:slf4j-log4j12:jar:1.1.0:compile
[INFO]       \- (log4j:log4j:jar:1.2.13:compile - omitted for conflict with 1.2.12)

Comme vous pouvez le voir, log4j v1.2.12 est préférable à v1.2.13.

Je sais que "Maven résout les conflits de version avec une stratégie de gains les plus proches" (voir http://maven.Apache.org/plugins/maven-dependency-plugin/examples/resolving-conflicts-using-the-dependency -tree.html ) mais ces deux dépendances semblent être à la même distance (deux niveaux d'imbrication, je me trompe?) donc je m'attends à ce que la plus récente soit utilisée.

Quelqu'un peut-il expliquer ce résultat?

Oui, log4j n'est pas explicitement déclaré dans ce POM (et je pense qu'il devrait l'être), mais j'aimerais mieux comprendre le fonctionnement de Maven.

THX

mavendependency-management
34
Pino

J'ai trouvé la réponse par moi-même à http://maven.Apache.org/guides/introduction/introduction-to-dependency-mechanism.html : "si deux versions de dépendances sont à la même profondeur dans l'arborescence des dépendances, jusqu'à Maven 2.0.8, on ne savait pas lequel gagnerait, mais depuis Maven 2.0.9, c'est l'ordre de la déclaration qui compte: la première déclaration gagne ".

Cela me semble une stratégie très discutable. : - \

60
Pino

si deux versions de dépendances sont à la même profondeur dans l'arborescence des dépendances, ou si ce n'est pas à la même profondeur, ce qui est plus proche du projet sera pointé vers le projet.

Il existe deux solutions pour résoudre ce problème une fois que vous connaissez votre niveau de dépendance.

First: si ces dépendances sont incluses dans le cadre d'un autre projet dans la bibliothèque, vous pouvez les supprimer manuellement, mais vous ne voulez pas que votre projet pointe cette dépendance comme elle était en raison de sa proximité avec votre projet. Vous pouvez exclure le pot d'un projet particulier comme indiqué ci-dessous dans votre projet pom.xml

 <dependency>
        <groupId>org.cassandraunit</groupId>
        <artifactId>cassandra-unit</artifactId>
        <version>3.1.3.2</version>
        <exclusions>
            <exclusion>
                <groupId>org.Apache.commons</groupId>
                <artifactId>commons-lang3</artifactId>
            </exclusion>
        </exclusions>
    </dependency>

Second: Vous ajoutez directement le pot de la version attendue dans le pom.xml de votre projet. Ce serait alors le pot le plus proche de votre projet.

En utilisant les deux méthodes mentionnées ci-dessus, vous pouvez résoudre le problème.

1
Arpan Saini