Apache Maven par Johann AVELINE
Conventions
Project Object Model (POM)
Chaque projet ou sous-projet est configuré par un POM qui contient les informations nécessaires à Maven pour traiter le projet (nom du projet, numéro de version, dépendances vers d'autres projets, bibliothèques nécessaires à la compilation, noms des contributeurs etc.). Ce POM se matérialise par un fichier pom.xml à la racine du projet. Cette approche permet l'héritage des propriétés du projet parent. Si une propriété est redéfinie dans le POM du projet, elle recouvre celle qui est définie dans le projet parent. Ceci introduit le concept de réutilisation de configuration. Le fichier pom du projet principal est nommé pom parent.
Les trois lettres POM sont l'acronyme de Project Object Model. Sa représentation XML est traduite par Maven en une structure de données qui représente le modèle du projet. Ces déclarations sont complétées par l'ensemble des conventions qui viennent ainsi former un modèle complet du projet utilisé par Maven pour exécuter des traitements.
La première partie du POM permet d'identifier le projet lui-même :
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.app</groupId>
<artifactId>my-app</artifactId>
<version>1</version>
</project>
- L'élément modelVersion permet de savoir quelle version de la structure de données "modèle de projet" est représentée dans le fichier XML. Les futures versions de Maven pourront ainsi exploiter des versions différentes de modèles en parallèle et introduire si nécessaire des évolutions dans le format de ce fichier.
- L'identifiant de groupe (groupId) permet de connaitre l'organisation, l'entreprise, l'entité ou la communauté qui gère le projet. Par convention, on utilise le nom de domaine Internet inversé, selon la même logique que celle généralement recommandée pour les noms de packages Java.
- L'identifiant de composant (artifactId) est le nom unique du projet au sein du groupe qui le développe. En pratique et pour éviter des confusions, il est bon d'avoir un artifactId unique indépendamment de son groupId.
- Enfin l'élément version permet de préciser quelle version du projet est considérée.La plupart des projets utilisent la formule <Version Majeure>.<Version Mineure>.<Correctif>.
La deuxième partie du POM concerne la construction du projet :
<build>
<sourceDirectory>src</sourceDirectory>
</build>
- L'approche déclarative utilisée par Maven permet de définir l'emplacement des fichiers sources. Si les conventions sur les noms de répertoires ont été respectées, ce bloc <build> n'est pas nécessaire.
Gestion des dépendances
La troisième partie du POM concerne les bibliothèques dont dépend le projet :
<dependencies>
<dependency>
<groupId>javax.mail</groupId>
<artifactId>mail</artifactId>
<version>1.4</version>
<dependency>
<dependency>
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
<version>1.4</version>
<dependency>
</dependencies>
- Une nouvelle fois, l'approche déclarative prend le dessus : il n'est pas necéssaire d'indiquer l'emplacement physique de ces bibliothèques (ex: /lib) mais uniquement les identifiants groupId + arifactId + version. Il s'agit des mêmes identifiants de groupe, de composant et de version utilisés pour un projet mais appliqués à une bibliothèque. Dans cet exemple nous souhaitons utiliser l'API standard JavaMail en version 1.4.
Dépendances transitives
Une des nouveautés de Maven 2 est la gestion des dépendances transitives. Avec Maven 1, il fallait déclarer chacun des JAR dont avait besoin, directement ou indirectement, l'application. Avec Maven 2, cela n'est plus nécessaire. En indiquant juste les bibliothèques dont l'application a besoin, Maven se charge des bibliothèques dont les bibliothèques de l'application ont besoin (et ainsi de suite).
Portée des dépendances
Dans une application d'entreprise du monde réel, il n'est pas nécessaire d'inclure toutes les dépendances dans l'application déployée. Certains des JARs sont nécessaires uniquement pour les tests unitaires, alors que d'autres seront fournis à l'exécution par le serveur d'application. En utilisant la technique de la portée de dépendances, Maven 2 permet d'utiliser certain JAR uniquement en cas de besoin et de les exclure du classpath dans le cas contraire. Maven met à disposition quatre portés de dépendances :- compile: Une dépendance de portée compile est disponible dans toutes les phases. C'est la valeur par défaut.
- provided: Une dépendance de portée provided est utilisée pour compiler l'application, mais ne sera pas déployée. Vous utiliserez cette portée quand vous attendez du JDK ou du serveur d'application qu'il vous mette le JAR à disposition. L'API servlet est un bon exemple.
- runtime: Les dépendances de portées runtime ne sont pas nécessaires pour la compilation, uniquement pour l'exécution, comme les drivers JDBC (Java Database Connectivity).
- test: Les dépendances de portées test sont uniquement nécessaires pour compiler et exécuter les tests (par exemple Junit).
Maven va ainsi télécharger les bibliothèques indiquées, à partir d'une source fiable, plutôt que de se contenter des fichiers JAR presents dans le répertoire /lib et dont la version et l'origine sont incertaines. L'espace contenant l'ensemble des bibliothèques téléchargées est un dépôt d'archives local (local repository) et respecte une convention.
| << page précédente | page suivante >> |
