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


    3.4. Dépendances d'un projet

    Maven sait gérer des dépendances internes et externes. Pour un projet Java, une dépendance externe est une bibliothèque comme Plexus, Spring ou Log4J. Un exemple de dépendance interne est un projet d'application web qui dépend d'un autre projet contenant les classes des services, des objets du domaine ou assurant la persistance. L'Exemple 3.3, « Dépendances d'un projet » donne un exemple des dépendances d'un projet.

    Exemple 3.3. Dépendances d'un projet

    <project>
      ...
      <dependencies>
        <dependency>
          <groupId>org.codehaus.xfire</groupId>
          <artifactId>xfire-java5</artifactId>
          <version>1.2.5</version>
        </dependency>
        <dependency>
          <groupId>junit</groupId>
          <artifactId>junit</artifactId>
          <version>3.8.1</version>
          <scope>test</scope>
        </dependency>
        <dependency>
          <groupId>javax.servlet</groupId>
          <artifactId>servlet-api</artifactId>
          <version>2.4</version>
          <scope>provided</scope>
        </dependency>
      </dependencies>
      ...
    </project>
    


    La première dépendance est une dépendance de compilation vers la bibliothèque XFire SOAP de chez Codehaus. Vous pouvez utiliser une dépendance de ce type dans votre projet lorsque celui-ci dépend d'une bibliothèque pour compiler, exécuter les tests et s'exécuter. La deuxième dépendance est une dépendance sur JUnit avec la portée (scope) test. Vous pouvez utiliser une dépendance dans le scope test lorsque vous n'avez besoin de cette bibliothèque que pour compiler et exécuter les tests. La dernière dépendance de l'Exemple 3.3, « Dépendances d'un projet » est une dépendance sur l'API Servlet 2.4. Cette dernière dépendance se trouve dans le scope provided. Vous pouvez utiliser le scope provided quand votre application a besoin d'une bibliothèque à la compilation ainsi que pour les tests et que cette bibliothèque est fournie par un conteneur à l'exécution.

    3.4.1. Scope de dépendance

    L'Exemple 3.3, « Dépendances d'un projet » nous a permis d'introduire brièvement trois des cinq scopes de dépendance : compile, test et provided. Le scope contrôle dans quel classpath vont se retrouver les dépendances et quelles seront celles qui seront intégrées à l'application. Regardons ces scopes plus en détail :

    compile

    compile est le scope par défaut ; toutes les dépendances sont dans ce scope compile si aucun scope n'est précisé. Les dépendances du scope compile se retrouvent dans tous les classpaths et sont packagées avec l'application.

    provided

    Les dépendances du scope provided sont utilisées lorsqu'elles doivent être fournies par le JDK ou un conteneur. Par exemple, si vous développez une application web, vous aurez besoin de l'API Servlet dans votre classpath pour pouvoir compiler une servlet, mais vous ne voudrez pas inclure l'API Servlet dans votre fichier WAR ; le JAR de l'API Servlet est fourni par votre serveur d'applications ou par votre conteneur de servlet. Les dépendances du scope provided font partie du classpath de compilation (mais pas de celui d'exécution). Elles ne sont pas transitives et ne seront pas packagées avec l'application.

    runtime

    Les dépendances du scope runtime sont des dépendances nécessaires à l'exécution de l'application et des tests, mais qui sont inutiles à la compilation. Par exemple, vous pouvez avoir besoin d'un JAR pour l'API JDBC à la compilation et uniquement de l'implémentation du driver JDBC à l'exécution.

    test

    Les dépendances du scope test sont des dépendances qui ne sont pas nécessaires à l'application durant son fonctionnement normal, elles ne servent que durant les phases de compilation et d'exécution des tests. Nous avons déjà parlé du scope test dans la ???.

    system

    Le scope system est assez proche du scope provided sauf que vous devez fournir un chemin explicite vers le JAR sur le système de fichiers local. Il permet la compilation utilisant des objets natifs faisant partie des bibliothèques système. On suppose que cet artefact est toujours présent et donc il ne sera pas cherché dans un dépôt. Si vous utilisez le scope system, vous devez automatiquement lui adjoindre une balise systemPath. Il est important de noter que l'utilisation de ce scope n'est pas recommandée (vous devriez toujours essayer de référencer des dépendances qui se trouvent dans un dépôt Maven public ou privé).