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


    10.3. Goals communs aux cycles de vie

    La plupart des cycles de vie de packaging possèdent des goals en commun. Si vous regardez les goals rattachés aux cycles de vie WAR et JAR, vous remarquerez que seule la phase package diffère. La phase package du cycle de vie WAR appelle war:war alors que cette même phase appelle jar:jar pour le cycle de vie JAR. La plupart des cycles de vie que vous rencontrerez partageront certains goals pour gérer les ressources, exécuter les tests et compiler votre code. Dans cette section, nous explorerons quelques-uns des goals utilisés sur plusieurs cycles de vie.

    10.3.1. Traiter les resources

    La plupart des cycles de vie rattachent le goal resources:resources à la phase process-resources. La phase process-resources "traite" les ressources et les copie dans le répertoire destination. Si vous n'avez pas personnalisé les répertoires par défaut définis dans le Super POM, Maven copiera les fichiers du répertoire ${basedir}/src/main/resources dans le répertoire ${basedir}/target/classes ou dans le répertoire défini dans ${project.build.outputDirectory}. En plus de les copier, Maven peut également appliquer des filtres aux ressources pour remplacer certains de leurs éléments. Tout comme dans le POM où les variables étaient définies par la notation ${...}, vous pouvez référencer des variables dans les ressources de votre projet en utilisant cette même syntaxe. Couplée aux profils, cette fonctionnalité peut être utilisée pour construire des artefacts configurés pour différentes plateformes de déploiement. Il est courant d'avoir besoin de construire des artefacts multi-environnement, en effet, un projet a souvent plusieurs environnements cibles : développement, tests, recette, production. Pour plus d'informations à propos des profils, consultez le Chapitre 11, Profils de Build.

    Pour illustrer ce filtrage des ressources, prenons l'exemple d'un projet possédant un fichier XML : src/main/resources/META-INF/service.xml. Vous voulez externaliser certaines variables de configuration dans un fichier properties. En d'autres termes, vous voulez référencer l'URL JDBC, l'utilisateur et le mot de passe de votre base de données, sans directement mettre ces valeurs en dur dans le fichier service.xml. À la place, vous désirez utiliser un fichier properties pour centraliser toutes les valeurs de configuration de votre programme. Cela vous permet de consolider toute la configuration dans un seul fichier properties, et simplifie la mise à jour des valeurs de configuration lors de la configuration d'un nouvel environnement. Commençons par regarder le contenu du fichier service.xml du répertoire src/main/resources/META-INF.

    Exemple 10.4. Utilisation des propriétés dans les ressources du projet

    <service>
      <!-- This URL was set by project version ${project.version} -->
      <url>${jdbc.url}</url>
      <user>${jdbc.username}</user>
      <password>${jdbc.password}</password>
    </service>
    


    Ce fichier XML utilise la même syntaxe pour gérer ses propriétés que celle que du POM. La première variable référencée est la variable project, celle-ci est une variable implicite qui est également disponible dans le POM. La variable project propose un moyen d'accéder à certaines informations du POM. Les trois variables suivantes sont jdbc.url, jdbc.username et jdbc.password. Ces variables sont définies dans un fichier de properties src/main/filters/default.properties.

    Exemple 10.5. default.properties dans src/main/filters

    jdbc.url=jdbc:hsqldb:mem:mydb
    jdbc.username=sa
    jdbc.password=
    

    Pour configurer le filtrage des ressources avec le fichier default.properties, nous avons besoin de préciser deux choses dans le POM du projet : une liste de fichiers de propriétés dans la balise filters de la configuration du build et un booléen qui permet à Maven de savoir si un répertoire doit être filtré. Le comportement par défaut de Maven est de ne pas effectuer de filtre mais de juste copier les ressources dans le répertoire destination : vous devez donc configurer explicitement le filtrage des ressources. Ce comportement par défaut permet d'éviter les mauvaises surprises comme, par exemple, filtrer sans que vous le désiriez des fichiers contenant des éléments ${...}.

    Exemple 10.6. Filtrage des ressources (remplacer les propriétés)

    <build>
      <filters>
        <filter>src/main/filters/default.properties</filter>
      </filters>
      <resources>
        <resource>
          <directory>src/main/resources</directory>
          <filtering>true</filtering>
        </resource>
      </resources>
    </build>
    


    Comme pour tous les répertoires dans Maven, celui contenant les ressources du projet ne se trouve pas forcément dans src/main/resources. Il ne s'agit que de la valeur par défaut définie dans le Super POM. Notez également que vous n'avez pas besoin de centraliser toutes vos ressources dans un unique répertoire. Vous pouvez les séparer dans plusieurs sous-répertoires dans src/main. Imaginez que votre projet contienne des centaines de fichiers XML et des centaines d'images. Au lieu de centraliser toutes vos ressources dans le répertoire src/main/resources, il voudrez probablement créer deux répertoires src/main/xml et src/main/images. Pour ajouter des répertoires à la liste des répertoires contenant les ressources, ajoutez la balise resource suivante dans la configuration de votre build.

    Exemple 10.7. Ajouter des répertoire ressources complémentaires

    <build>
      ...
      <resources>
        <resource>
          <directory>src/main/resources</directory>
        </resource>
        <resource>
          <directory>src/main/xml</directory>
        </resource>
        <resource>
          <directory>src/main/images</directory>
        </resource>
      </resources>
      ...
    </build>

    Lorsque vous construisez un projet qui produit une application en ligne de commande ou console, vous voudrez souvent écrire des scripts shell et les référencer dans le JAR produit par un build. Quand vous utilisez le plugin Assembly pour distribuer votre application via un ZIP ou un TAR, vous pouvez placer tous vos scripts dans un répertoire du type src/main/command. Dans la configuration des ressources du POM suivant, vous verrez comment nous pouvons utiliser le filtrage des ressources et avec une référence vers une variable pour modifier le nom du JAR. Pour plus d'informations sur le plugin Maven Assembly, consultez le Chapitre 14, Maven Assemblies.

    Exemple 10.8. Fitrage de resources Scripts

    <build>
      <groupId>org.sonatype.mavenbook</groupId>
      <artifactId>simple-cmd</artifactId>
      <version>2.3.1</version>
      ...
      <resources>
        <resource>
          <filtering>true</filtering>
          <directory>${basedir}/src/main/command</directory>
          <includes>
            <include>run.bat</include>
            <include>run.sh</include>
          </includes>
          <targetPath>${basedir}</targetPath>
        </resource>
        <resource>
          <directory>${basedir}/src/main/resources</directory>
        </resource>
      </resources>
      ...
    </build>


    Si vous exécutez la commande mvn process-resources dans ce projet, vous vous retrouverez avec deux fichiers dans ${basedir} : run.sh et run.bat. Nous avons inclus ces deux fichiers dans la balise resource, configuré le filtrage, et affecté le targetPath à la valeur ${basedir}. Dans une seconde balise resource, nous avons configuré le chemin par défaut des ressources pour qu'elles soient copiées sans filtrage dans le répertoire de destination. L'Exemple 10.8, « Fitrage de resources Scripts » montre comment déclarer deux répertoires ressources et les configurer différemment. Le projet de l'Exemple 10.8, « Fitrage de resources Scripts » doit disposer un fichier run.bat dans le dossier src/main/command qui contient le code suivant :

    @echo off
    java -jar ${project.build.finalName}.jar %*
    

    Après avoir exécuté la commande mvn process-resources, un fichier nommé run.bat devrait apparaître dans ${basedir}, en voici son contenu :

    @echo off
    java -jar simple-cmd-2.3.1.jar %*
    

    La possibilité de personnaliser le filtrage pour un sous-ensemble spécifique de ressources est l'une des raisons de séparer vos ressources par type sur un projet. Plus un projet est complexe, plus il sera avantageux de séparer les ressources dans différents répertoires. L'alternative au fait de conserver différentes sortes de ressources nécessitant différentes configurations de filtre dans des répertoires différents est d'utiliser un ensemble complexe de pattern 'include' et 'exclude' pour différencier les types de configuration. Cette seconde solution est beaucoup plus complexe à maintenir et à mettre en place.