L’outil d’automatisation Maven2

Maven est un outil dont la notoriété et l’utilisation augmente dans le monde Java. Son utilisation croit également dans le cadre de l’entreprise. D’autre part, son utilisation se répand largement dans les projets libres. Il facilite largement la tâche de recompiler un projet libre à partir du code source. Je tenterai ici d’expliquer pourquoi.

Il s’agit notamment d’un outil d’automatisation des tâches, même si ce point de vue est un peu réducteur. Il remplace avantageusement Ant pour la partie automatisation. Dans cette présentation, je me limite à Maven2. En effet, Maven1 était un Ant un peu amélioré sans intérêt réel maintenant.

Maven comme Ant permettent d’automatiser les tâches dans un projet Java, comme la compilation, la génération d’archive, de rapport. Dans Ant, on définit certaines tâches, cela ressemble un peu à de la programmation. C’est donc bien adapté à l’état d’esprit d’un développeur. Mais finalement, on a l’impression redéfinir la roue à chaque fois et les scripts Ant peuvent devenir très longs, peu normalisés et difficiles à comprendre par une personne étrangère à l’équipe projet. Quant à Maven, il se base sur un principe complètement différent de Maven. On ne déclare pas de tâches, elles sont prédéfinies. C’est assez logique. Un projet Java doit être compiler, il devrait être testé, il doit permettre la création d’une archive comme un jar ou un war pour être utilisé facilement par d’autres projets. Donc la commande « mvn test » exécute les tests unitaires, « mvn package » génère l’archive associée au projet, et ceci pour tous les projets utilisant Maven. Il est possible de générer avec Maven, les rapports associés aux outils de qualité comme checkstyle et cobertura.

Comment fonctionne alors ce magique outil Maven ? Le développeur définit dans le fichier pom.xml la structure du projet. Je ne déclare pas les actions à effectuer sur le projet mais comment est structuré le projet. Cette approche déclarative n’est pas forcément la plus proche de l’état d’esprit du développeur mais est ici beaucoup plus efficace. Un autre point diminue fortement la taille du fichier pom.xml, Maven se base sur des conventions. Le code source se trouve par défaut dans le répertoire src/main/java. Il est toujours possible de le placer ailleurs mais finalement il est mieux de suivre les conventions. Le seul cas où il reste utile de surcharger les conventions est lorsqu’on reprend d’anciens projets archivés sous CVS. Le déplacement d’un fichier avec CVS fait perdre l’historique.

Maven gère également les dépendances entre projets avec les versions. Un projet java classique va utiliser le framework de test Junit (version 3 ou 4), la librairie log4j pour la gestion des traces techniques. On déclare explicitement les dépendances et leurs portées (test, compile, runtime). Ceci est sans doute une réponse provisoire au grand désordre qu’est la non gestion des dépendances dans le monde Java (et je suis très poli ici : c’est le vrai B***).

Il demeure cependant quelques problèmes lors de l’utilisation de Maven. Le premier est le manque d’intégration dans Eclipse. Ce problème était important il y a quelques temps. Maintenant, il existe deux plugins m2eclipse et q4e. J’utilise le premier dans mon activité professionnelle, ceci de plus en plus. Le second q4e est un projet Google. Il apparaît plus ambitieux que m2. Il propose notamment une vue graphique des dépendances. Maintenant, l’installation par le site update ne fonctionne pas. Je ne le conseille pas un premier temps et je vous propose m2.

Les plugins ne font pas tout. Il existe un manque dans Eclipse au niveau de la hiérarchie des projets. Tous les projets Eclipse sont au même niveau. Tandis que Maven autorise des hiérarchies de projets. En fait ceci est imposé par Maven du fait qu’un projet Maven correspond à un seul artefact (pas deux ou plusieurs). Ceci risque d’engendrer un nombre important de projets Eclipse. Notons qu’Eclipse n’a pas de notion de portée des dépendances. Donc si vous utiliser Junit, une librairie Junit*.jar apparaît dans la liste des dépendances alors qu’avec Maven on peut indiquer que cette dépendance ne concerne que la partie des tests, et non l’utilisation de l’archive dans un autre projet.

Autre point délicat, je découvre régulièrement des petits bugs dans les plugins Maven de métriques et de qualité du code.

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s


%d blogueurs aiment cette page :