Maven : mise en oeuvre pratique et migration depuis ANT

Publié par Romain Linsolas, le 21/06/2007, dans Uncategorized

Maven est souvent perçu comme le remplaçant de ANT qui règle tous les problèmes de build et qui est simple à mettre en œuvre. Cependant, la mise en œuvre de Maven implique certains changements d’infrastructure importants qui ne sont pas toujours explicités de prime abord.


Dans les structures de projets « standard » avant l’introduction de Maven, on avait typiquement un répertoire projet géré en version, et contenant des scripts de build ANT, du code source et un répertoire libs contenant un collection de jars utilisés pour le projet. Avec potentiellement des ressources (images, etc.), comme le monte le schéma ci-dessous :

nl19_maven_1.jpg

Pour reconstruire l’application, on peut normalement extraire ces fichiers de l’outil de gestion de version et relancer un build (une seule commande automatisée). Le build va inclure les librairies externes dans le classpath, recompiler, relancer les tests unitaires, etc. et packager l’application avec toutes ses dépendances (fichiers jars placés dans le répertoire lib).

Maven quant à lui propose un système de gestion des librairies transverse aux projets : le répertoire projet contient les fichiers de code source, et le traditionnel build.xml contenant les scripts ANT est remplacé par un fichier pom.xml :

nl19_maven_2.png

Les librairies externes sont récupérées par Maven depuis un repository de librairies. Pour cela, Maven définit une structure bien précise de stockage des jars, avec leur version, les dépendances entre jars, etc. Le repository peut stocker plusieurs versions d’un même jars, ce qui permet une vision très transverse : un projet A peut utiliser JUnit-3.8.jar, et un projet B utilisera junit-4.0.jar, en accédant au même repository.

Un effet de bord qui est souvent sous-estimé lors de la mise en place de Maven est la dépendance vers ce repository de librairies : dans le modèle ANT, on est uniquement dépendant du système de gestion de version pour reconstruire l’application. Typiquement, l’outil de gestion de version tourne sur un serveur au moins backupé, voire avec un système de bascule en cas de crash d’une machine.

Dans le modèle Maven, les fichiers du projet sont répartis entre le système de gestion de version (pour le code source) et le repository pour les librairies externes. On ne peut pas reconstruire l’application si on n’a pas un repository accessible. La mise en place de Maven implique donc la mise en place d’un repository avec le même niveau de disponibilité que le serveur hébergeant l’outil de gestion de version. Cela est parfois négligé au départ et ensuite bâclé lorsqu’on rencontre le problème en cours de mise en oeuvre.

Concernant les librairies gratuites et standard (junit, log4j, spring, etc.), on peut directement accéder à un repository Maven public via internet. Il faut penser à vérifier que l’accès à Internet n’est pas trop restreint…
Par contre, il est aussi nécessaire de gérer les librairies « maison » (framework, socle technique, etc.) et potentiellement les librairies de produits commerciaux. Maven préconise donc de mettre en place un repository de librairies pour cela. C’est certainement la cible à atteindre, cela permettra aussi en particulier de gérer les dépendances entre les différents projets internes. Cependant, pour un projet isolé, mettre en place un serveur Maven backupé pour stocker quelques jars peut au début paraître bien lourd.

Maven propose une solution alternative déconseillée mais néanmoins bien pratique dans certains cas: lorsqu’on définit une dépendance vers une librairie, on peut préciser un « systemPath » pour cette librairie et préciser le chemin du fichier jar, typiquement dans le répertoire libs. Cela permet de s’affranchir du repository Maven, qui peut parfois être coûteux en temps de mise ne place et de support. En particulier, pour effectuer une migration de ANT vers Maven, on peut dans une première étape conserver toutes les librairies « maison » dans le répertoire libs et définir des dépendances avec un systemPath dans le fichier pom.xml. La migration s’effectue alors entre deux modèles assez proches, ce qui réduit les risques et les coûts.

http://maven.apache.org/pom.html#Dependencies

Guillaume Tardif

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

By submitting this form, you accept the Mollom privacy policy.