De l’intérêt de Maven 2

Kézako

Maven 2 est un (puissant) outil open source créé pour gérer la « périphérie technique » d’un projet java : de sa description (version, dépendances) à son déploiement en passant par l’ensemble des étapes standard (compilation, tests unitaires, construction, installation, etc. …) Je ne rentrerai pas trop dans le détail, vous invitant à consulter l’article très détaillé sur maven 2 depuis le site développez.com. L’élément à bien retenir ici est le fichier de description de votre projet : le pom.xml. C’est dans ce fichier que l’ensemble des déclarations sera fait. Pour lancer maven, il vous suffit d’appeler un « but » (ou goal en anglais). Le lancer via maven consiste à dire que vous souhaitez atteindre ce but (cet objectif). Par exemple, la commande mvn compile indique que vous souhaitez compiler votre projet.

Les dépendances

L’un des éléments à retenir consiste en la gestion des dépendances d’un projet proposée avec une gestion de la résolution des dépendances induites : concrètement, il suffit d’indiquer que votre projet compte la librairie struts en version 1.3.0 dans ses dépendances, et maven ajoutera automatiquement les autres librairies nécessaires au bon fonctionnement de struts, gérant au passage tout conflit potentiel avec d’autres dépendances. Pour les Linuxiens, ce système est tout à fait similaire au fonctionnement de APT (Debian, Ubuntu) ou YUM (Red Hat, Fedora). La communauté Maven 2 maintient donc un repository public qui référence l’ensemble des librairies disponibles à l’ajout. Lors d’une compilation, l’outil rapatrie localement les JAR et les place dans un répertoire structuré de la même manière que ce repository distant, vous permettant – ce point est essentiel – d’ajouter vos propres librairies.

Les plugins

Pour rester extensible (c’est dans l’ère du temps), maven 2 gère des plugins. On compte notamment parmi eux le plugin « eclipse » générant les fichiers .classpath et .project utilisé par l’IDE au moment de la compilation. Une partie dédiée au WTP est également en place pour gérer le déploiement d’une webapp sur le serveur applicatif déclaré via ce dernier. Maven dispose d’un « repository de plugins » (URL Internet) dans lequel il va aller chercher toute déclaration de plugin faite dans votre fichier pom.xml. Par exemple, si vous déclarez l’utilisation du plugin WTP (section <build>), maven va télécharger le plugin en question et l’appliquera à votre projet.

Conclusion

A partir de ces différents constats, il devient intéressant de gérer l’ensemble du processus de déploiement d’un projet à l’aide de maven 2, pour éviter d’utiliser trop d’outils différents concernant les tâches connexes à vos développements.

Quand Flex rentre en action

Pourquoi maven 2 pour Flex ?

Maven va donc compiler la partie Java, lancer d’éventuels tests unitaires, mais dans un projet Flex, il faudra au préalable que les .as et .mxml aient été compilés et inclus dans les bons répertoires du projet. Mais qu’en est-il si l’on gère plusieurs projets et qu’ils ont en commun des libraires SWC de composants? Pas très pratique de copier les fichiers directement en tant que ressource et risquer des erreurs de copies ou de mises à niveau lors de changements de version. Heureusement, vous n’êtes pas le seul à vous être posé la question…

Le plugin Maven 2 - Flex 2

L’équipe de ServeBox propose un plugin Maven gérant la compilation et le déploiement d’applications et de librairies Flex (par le biais d’un SDK installé localement). Tous les détails sur ce plugin figurent à l’adresse suivante : Plugin Flex 2 pour maven sur ServeBox. Pour reprendre succinctement les travaux effectués à l’heure actuelle, vous devez, en plus d’installer maven 2 :

  • installer les artifacts (librairies) SWC du framework Flex dans votre repository local,
  • pour chaque projet :
    • déclarer le type de « packaging » de votre projet (SWF pour une application et SWC pour une librairie Flex),
    • déclarer le chemin vers le plugin de ServeBox (dans le repository de plugins) afin que le type de packaging SWF ou SWC soit reconnu, ainsi que les buts (goal) comme flex2:makeswc.

On peut donc tout à fait imaginer que vous installiez dans votre repository local des librairies comme flex-lib ou encore vos propres librairies (un framework local ou que sais-je encore), pour les utiliser comme dépendance de votre projet (au même titre qu’une dépendance Java). Un mot pose pourtant encore problème dans cette conclusion : « local ». Eh oui, vous êtes sur votre machine et ne partagez pas votre installation avec votre entourage.

Comment ajouter des librairies dans un repository partagé par un groupe de travail ?

Le problème se posait déjà dans le monde Java : il n’est pas rare qu’un projet dépende de librairies n’appartenant pas au monde libre (oracle, …) et le système (très appréciable) de gestion de dépendances de maven 2 à tendance à donner des idées pour mutualiser les développements. Une réponse existe sous le nom de Proximity. Comme vous le verrez peut-être en suivant ce lien, Proximity est un proxy pour maven. En répliquant les dépendances demandées lors d’une exécution de maven, son intérêt est multiple :

  • réduire les temps de rapatriement de manière générale,
  • répondre en cas d’indisponibilités ponctuelles du repository public de maven 2,
  • ajouter des librairies dans des repository personnalisés fonctionnant comme le repository public de maven 2.

Selon votre organisation, vous pouvez tout à fait installer une instance de proximity pour y créer un repository personnalisé, et ainsi mutualiser vos propres librairies.

J’espère que cette approche générale sur le sujet vous donnera l’envie d’aller un peu plus loin. La prochaine fois, j’entrerai sur un cas pratique d’une application Flex développée sous eclipse WTP à l’aide de maven 2.

A bientôt !