Dans un soucis de qualité et de traçabilité Apache Maven a introduit et imposé dès le départ la notion de version pour identifier les projets et leurs livrables. Cependant il faut bien avouer que pendant longtemps il n’y avait pas d’outil à la disposition des équipes pour analyser et manipuler les différentes versions utilisées dans les descripteurs Maven. Ce manque a été en partie comblé il y a un peu plus d’un an par la création du plugin versions, hébergé sur http://mojo.codehaus.org que je me propose de vous présenter. Cet article est un complément aux explications que j’ai pu donner dans la rubrique "les mains dans le cambouis" de l’épisode 16 du podcast Les Cast Codeurs.
Cet article est basé sur la version 1.1 du plugin versions publiée en octobre 2009.
Apache Maven permet nativement de découper un projet en sous-modules. Chaque module est un élément autonome avec son propre cycle de vie. Maven utilise ce que l’on appel le “reactor” pour orchestrer dans un projet l’appel des différents modules en fonction de leurs dépendances.
Le concept de module, permet d’affiner la granularité des livrables et de rendre plus flexible et évolutive l’architecture de l’application. Cependant lorsque le nombre de modules d’un projet augmente cela va souvent de pair avec le nombre de lignes de code, de tests et de packages à créer. La construction du projet prend donc de plus en plus de temps à en devenir un frein pour la productivité du développeur (moi je ne trouve rien de plus énervant lorsque je développe que de devoir attendre que ma machine me rende la main).
Il existe pourtant des fonctionnalités du “reactor” qui permettent à Maven de contrôler finement quels sont les modules d’un projet sur lesquels on souhaite appeler un traitement. Même si elles existent depuis près de deux ans, ces fonctionnalités sont encore peu connues et utilisées malgré leurs utilités indéniables (faute à la documentation ?). Ce billet illustre mes rapides explications de l’épisode 20 du podcast Les Cast Codeurs. Il détaille l’utilisation de 4 options de la ligne de commande pour Maven 2.1 et versions ultérieures. Vous pouvez très bien faire la même chose avec le plugin reactor et les versions 2.0.x de Maven mais il faudra taper sur plus de touches de votre clavier car la syntaxe est bien moins synthétique. Continue reading Build partiel avec Maven : Construire moins pour aller plus vite.→
Une chose ennuyeuse lorsque l’on démarre un nouveau projet Maven avec différents sous-modules et que l’on veut en gérer les versions dans Subversion c’est qu’il faut pour chaque module configurer la propriété svn:ignore afin de lui dire de ne jamais publier sur le serveur les fichiers ou répertoires que l’on ne veut pas partager avec le reste de l’équipe.
Le gros avantage de Maven ce sont ses conventions et en particulier sur l’organisation des répertoires (sans cela autant faire du script).
La force des OS Unix-like (Linux, Macos, …) c’est la panoplie d’outils super-puissants en ligne de commande. Continue reading Subversion : Exclure en masse les fichiers et répertoires générés d’un projet Maven→
Dans un soucis de qualité et de traçabilité Apache Maven a introduit et imposé dès le départ la notion de version pour identifier les projets et leurs livrables. Cependant il faut bien avouer que pendant longtemps il n’y avait pas d’outil à la disposition des équipes pour analyser et manipuler les différentes versions utilisées dans les descripteurs Maven. Ce manque a été en partie comblé il y a un peu plus d’un an par la création du plugin versions, hébergé sur http://mojo.codehaus.org que je me propose de vous présenter.
Cet article est un complément aux explications que j’ai pu donner dans la rubrique "les mains dans le cambouis" de l’épisode 16 du podcast Les Cast Codeurs.
