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


    11.5. Trucs et Astuces

    Les profils encouragent la portabilité du build. Si vous avez besoin de configurer avec délicatesse votre build pour qu'il puisse s'exécuter sur différentes plateformes ou pour construire différents artefacts selon la plateforme cible, alors les profils peuvent améliorer sa portabilité. Les profils définis dans les fichiers settings.xml diminuent la portabilité d'un build puisque les développeurs doivent échanger cette information supplémentaire. Les sections qui vont suivre présentent des guides et des suggestions pour l'utilisation de profils Maven dans votre projet.

    11.5.1. Environnements communs

    Une des principales raisons à l'utilisation de profils Maven est de fournir la configuration spécifique à un environnement. Dans un environnement de développement, vous voudrez produire du bytecode avec les informations nécessaires pour le débogage et vous voudrez configurer votre système pour qu'il utilise une base de données de développement. Dans un environnement de production, vous souhaiterez produire un JAR signé et configurer votre système pour qu'il utilise la base de données de production. Dans ce chapitre, nous avons défini un certain nombre d'environnements avec des identifiants comme dev et prod. On peut faire plus simple en définissant des profils qui seront activés par des propriétés de l'environnement et en utilisant ces propriétés pour tous vos projets. Par exemple, si chaque projet a un profil development activé par une propriété appelée environment.type ayant pour valeur dev, et si ces mêmes projets avaient un profil production activé par la présence d'une propriété environment.type ayant pour valeur prod, vous pourriez alors créer un profil dans votre fichier settings.xml qui définirait une propriété environment.type avec pour valeur dev sur votre machine de développement. Ainsi, chaque projet doit définir un profil dev activé par la même variable d'environnement. Voyons comment appliquer tout cela : le fichier settings.xml suivant définit un profil dans ~/.m2/settings.xml qui spécifie la valeur dev pour la propriété environment.type.

    Exemple 11.6. Le fichier ~/.m2/settings.xml définit un profil par défaut qui spécifie la propriété environment.type

    <settings>
      <profiles>
        <profile>
          <activation>
            <activeByDefault>true</activeByDefault>
          </activation>
          <properties>
            <environment.type>dev</environment.type>
          </properties>
        </profile>
      </profiles>
    </settings>
    


    Lorsque vous exécutez Maven sur votre poste avec cette configuration, ce profil sera activé et la propriété environment.type aura pour valeur dev. Vous pouvez utiliser cette propriété pour activer les profils définis dans le fichier pom.xml d'un projet comme nous allons le voir. Regardons donc, comment le fichier pom.xml définirait un profil qui serait activé par le fait que la propriété environment.type ait pour valeur dev.

    Exemple 11.7. Profil d'un projet activé quand environment.type vaut 'dev'

    <project>
      ...
      <profiles>
        <profile>
          <id>development</id>
          <activation>
            <property>
              <name>environment.type</name>
              <value>dev</value>
            </property>
          </activation>
          <properties>
            <database.driverClassName>com.mysql.jdbc.Driver</database.driverClassName>
            <database.url>
              jdbc:mysql://localhost:3306/app_dev
            </database.url>
            <database.user>development_user</database.user>
            <database.password>development_password</database.password>
          </properties>
        </profile>
        <profile>
          <id>production</id>
          <activation>
            <property>
              <name>environment.type</name>
              <value>prod</value>
            </property>
          </activation>
          <properties>
            <database.driverClassName>com.mysql.jdbc.Driver</database.driverClassName>
            <database.url>jdbc:mysql://master01:3306,slave01:3306/app_prod</database.url>
            <database.user>prod_user</database.user>
          </properties>
        </profile>
      </profiles>
    </project>
    


    Ce projet définit de nouvelles propriétés comme database.url et database.user qui pourraient être utilisées pour configurer un plugin Maven ailleurs dans le fichier pom.xml. Il existe de nombreux plugins qui peuvent manipuler une base de données, exécuter du SQL, ou comme le plugin Maven Hibernate3, peuvent générer un ensemble d'objets annotés utilisés par les frameworks de persistance. Certains de ces plugins peuvent être configurés dans un fichier pom.xml grâce à ces propriétés. Ces propriétés peuvent aussi être utilisées pour filtrer des ressources. Dans cet exemple, comme nous avons défini un profil dans le fichier ~/.m2/settings.xml qui spécifie la valeur dev pour environment.type, le profil de développement sera toujours actif à chaque exécution de Maven sur cette machine. Par contre, si nous voulions modifier ce comportement par défaut, nous pourrions préciser la valeur de cette propriété en ligne de commande. Si nous avons besoin d'activer le profil de production, nous pourrions exécuter Maven avec la commande :

    ~/examples/profiles $ mvn install -Denvironment.type=prod

    Spécifier une propriété en ligne de commande surchargera la valeur par défaut définie dans le fichier ~/.m2/settings.xml. Nous aurions pu aussi définir un profil avec un id "dev" et l'invoquer directement avec l'argument -P en ligne de commande, mais l'utilisation de cette propriété environment.type nous permet d'écrire de nouveaux fichiers pom.xml en respectant ce standard. Tous vos projets pourraient posséder un profil qui serait activé par la même propriété environment.type définie dans les fichiers ~/.m2/settings.xml de chaque développeur. Ainsi, les développeurs peuvent partager une configuration commune pour le développement sans avoir à la définir dans des fichiers settings.xml non-portables.