| Ce site met a disposition le build journalier de la traduction francaise du Maven: The Definitive Guide Consultez : | ![]() |
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.
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.