Ce site met a disposition le build journalier de la traduction francaise du Maven: The Definitive Guide
Consultez :
  • Les documents de reference sur le projet original
  • Les sources de la traduction fr sur GitHub
  • maven


    9.4.5. Résolution des conflits

    À certains moments, vous aurez besoin d'exclure une dépendance transitive lorsque votre projet dépend d'un autre projet et que vous voulez retirer complètement la dépendance transitive ou que vous souhaitez la remplacer par une autre qui apporte la même fonctionnalité. L'Exemple 9.7, « Exclusion d'une dépendance transitive » présente une dépendance vers le projet-a qui exclut la dépendance transitive vers le projet-b.

    Exemple 9.7. Exclusion d'une dépendance transitive

    <dependency>
      <groupId>org.sonatype.mavenbook</groupId>
      <artifactId>project-a</artifactId>
      <version>1.0</version>
      <exclusions>
        <exclusion>
          <groupId>org.sonatype.mavenbook</groupId>
          <artifactId>project-b</artifactId>
        </exclusion>
      </exclusions>
    </dependency>


    Souvent, vous voudrez remplacer une dépendance transitive par une autre implémentation de la fonctionnalité. Par exemple, si vous dépendez d'une bibliothèque qui elle-même dépend de l'API JTA de Sun, vous pouvez vouloir remplacer cette dépendance transitive. Hibernate en est un bon exemple. Hibernate dépend du JAR de l'API JTA de Sun qui n'est pas disponible sur le dépôt central de Maven car il n'est pas librement distribuable. Heureusement, le projet Apache Geronimo a créé une implémentation indépendante de cette bibliothèque qui est librement redistribuable. Pour remplacer une dépendance transitive par une autre, vous devrez exclure la dépendance transitive et ajouter l'autre dépendance à votre projet. L'Exemple 9.8, « Exclusion et remplacement d'une dépendance transitive » donne un exemple d'un tel remplacement.

    Exemple 9.8. Exclusion et remplacement d'une dépendance transitive

    <dependencies>
      <dependency>
        <groupId>org.hibernate</groupId>
        <artifactId>hibernate</artifactId>
        <version>3.2.5.ga</version>
        <exclusions>
          <exclusion>
            <groupId>javax.transaction</groupId>
            <artifactId>jta</artifactId>
          </exclusion>
        </exclusions>
      </dependency>
      <dependency>
        <groupId>org.apache.geronimo.specs</groupId>
        <artifactId>geronimo-jta_1.1_spec</artifactId>
        <version>1.1</version>
      </dependency>
    </dependencies>

    Dans l'Exemple 9.8, « Exclusion et remplacement d'une dépendance transitive », rien n'indique que la dépendance geronimo-jta_1.1_spec en remplace une autre, il se trouve juste qu'il s'agit d'une bibliothèque qui présente la même API que la dépendance JTA originale. Voici d'autres raisons pour lesquelles vous voudriez exclure ou remplacer des dépendances transitives :

    1. Le groupId ou l'artifactId de l'artefact a changé alors que le projet nécessite une version avec l'autre nom de cet artefact, ce qui fait que vous vous retrouvez avec deux copies du même projet dans votre classpath. Normalement, Maven détecte ce genre de conflit et utilise une unique version du projet, mais quand les groupId et artifactId sont différents, Maven les considère comme deux bibliothèques distinctes.

    2. Un artefact n'est pas utilisé dans votre projet et la dépendance transitive n'a pas été rendue optionnelle. Dans ce cas, vous voulez exclure cette dépendance non requise pour votre projet car vous essayez de réduire le nombre de bibliothèques que vous redistribuez avec votre application.

    3. Un artefact est fourni par votre conteneur à l'exécution et donc il ne doit pas être inclus par votre build. Par exemple, si une dépendance dépend de l'API Servlet et que vous voulez être sûr que cette dépendance transitive ne se retrouve pas dans le répertoire WEB-INF/lib de l'application web.

    4. Pour exclure une dépendance qui peut être une API avec plusieurs implémentations. C'est le cas présenté dans l'Exemple 9.8, « Exclusion et remplacement d'une dépendance transitive » ; où une API de Sun qui demande une acceptation d'une licence et une installation manuelle dans un dépôt personnel (le JAR JTA de Sun) peut être remplacée par une version librement redistribuable de la même API disponible sur le dépôt central de Maven (l'implémentation JTA de Geronimo).