mvn arnaud:blog

Je m’en vais faire ma quiche … Lorraine (Maven @ Lorraine JUG)

Arnaud Héritier — Wed, 26 May 2010 16:09:18 +0000

Et oui, même les meilleures choses ont une fin. Mardi prochain, le 1er Juin, je ferai ma dernière présentation de Maven devant un JUG.

Rassurez vous c’est simplement la dernière avant la pause estivale !! Je reviendrai.
Cela sera donc cette fois au LorraineJUG, près de Nancy, à l’Ecole Supérieure d’Informatique et Applications de Lorraine (193 av. Paul Muller, 54602 Villers-lès-Nancy).
Etant tout seul cette fois-ci vous n’aurez pas la « chance » (?) de nous voir faire notre numéro de Fred & Jamy (C’est pas sorcier sur France3) avec Nicolas, comme nous avons pu le faire au Paris JUG.
En revanche nous pourrons voir beaucoup plus de choses. Le menu étant riche, vous aurez donc le choix des plats à consommer en fonction de vos envies (et pour ne pas faire une indigestion). Voici la carte :

Un tour d’horizon du produit, ses différentes fonctionnalités et son positionnement par rapport à la concurrence,
Son histoire, retour vers le futur, ce que nous réserve Maven 3.x.
Son ecosystem, comme les gestionnaires de référentiels de binaires, les serveurs d’intégration continue, les tableaux de bord qualité, l’IDE,
Les bonnes et mauvaises pratiques d’utilisation,
Quelques cas d’usages méconnus (sécurisation des passwords, release d’un projet, options du réacteur),

Comme à chaque session un exemplaire de notre livre Apache Maven sera à gagner (tombola réservée aux membres).
Aprés la conférence, l’équipe du Lorraine JUG organisera un barbecue sur la terrasse de la cafétéria de l’ESIAL (en espérant que dieu Météo soit de notre coté). Si vous souhaitez y participer, envoyez un e-mail à info@lorrainejug.org. Une petite participation de 3€ sera demandée aux non-membres.
J’espère vous retrouver nombreux et n’oubliez pas de vous inscrire !!!

MAJ 9 Juin : Ci-dessous les slides de cette présentation.

Rating: 9.0/10 (1 vote cast)

Le bug Maven du jour : MRESOURCES-104

Arnaud Héritier — Tue, 27 Apr 2010 20:18:09 +0000

Il parait que je dis toujours que du bien de Maven (c’est tout du moins ce que certains ressentent en écoutant le podcast Les Cast Codeurs). C’est pourtant, je pense, loin d’être la vérité et ceux qui peuvent assister aux différents Java Users Groups que j’ai pu présenter doivent pouvoir confirmer que je n’hésite pas aussi à casser du sucre dessus.
Certainement pour me punir voilà que je tombe ce soir sur un bug qui m’a fait perdre 30 minutes. Je ne compte pas rédiger un blog par jour pour décrire un bug Maven (même si il y aurait largement de quoi faire) mais en partageant l’information j’espère éviter à quelques autres ce soucis.

Tout débute par un sous projet de GateIn (WSRP) dans lequel on souhaite filtrer un fichier de ressources. Jusque là, rien d’exceptionnel, cela fait partie des fonctionnalités de Maven depuis des années.
On rajoute dans le POM l’activation du filtrage :
xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> ... src/main/resources true
Nous plaçons un fichier wsrp.properties dans le répertoire src/main/resources avec la propriété ${project.version} pour que Maven la filtre :
# # JBoss, a division of Red Hat # Copyright 2010, Red Hat Middleware, LLC, and individual # contributors as indicated by the @authors tag. See the # copyright.txt in the distribution for a full listing of # individual contributors. # # This is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as # published by the Free Software Foundation; either version 2.1 of # the License, or (at your option) any later version. # # This software is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU # Lesser General Public License for more details. # # You should have received a copy of the GNU Lesser General Public # License along with this software; if not, write to the Free # Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA # 02110-1301 USA, or see the FSF site: http://www.fsf.org. # wsrp.service.version=${project.version}
On lance Maven et on s’attend à ce que la propriété soit remplacée dans le fichier properties copiée dans le répertoire target/classes….. mais rien !!
Je me mets alors à tester la syntaxe alternative @project.version@ ainsi qu’un propriété simple injectée via les POM ou la ligne de commande …. rien. Pas de filtrage.
Je commence alors à tester avec différentes versions du plugin resources (le projet utilise la version 2.4.1). Je suis d’ailleurs bien content d’avoir mis sous la forme d’une propriété toutes les versions des plugins pour faire ce genre de test en passant la valeur en ligne de commande. 2.4, 2.4.1, 2.4.2 KO. Par contre la 2.3 fonctionne.
C’est énorme !!!! Comment le filtrage peut ne pas fonctionner et ce sur les 3 versions du plugin ?
Je cherche dans les bug ouverts et voilà que je découvre l’horrible bug MRESOURCES-104 !!
Les délimiteurs des tokens/propriétés à remplacer/filtrer sont par défaut @XXXX@ ou ${XXXX}. Le bug se trouve au niveau du parsing des fichiers car si le plugin trouve un délimiteur de début sans fin, il s’emmele les pinceaux et arrête de filtrer.
De ce fait si dans le fichier à filtrer on trouve un caractère @ seul, comme dans l’entête JBoss, le filtrage ne fonctionne pas.
Il existe cependant un contournement indiqué dans les commentaires qui consiste à désactiver les délimiteurs par défaut pour ne définir que la version ${} :
xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> ... src/main/resources true maven-resources-plugin ${*} false
Et voilà comment j’ai perdu 30 minutes. Et oui Maven n’est pas magique et il existe des bugs !! Le mythe est tombé.
Mais une fois de plus lorsque l’on propose des services de plus en plus haut complexes on s’expose à créer des bugs encore plus pervers. Maintenant je n’ai plus qu’à voir si en 30 minutes j’arrive à le corriger.
Est ce que c’est pour cela que je vais remettre en cause les fondements de Maven ? Et bien non. Rien n’est parfait mais je crois en la nécessité de standardiser le build et je ne pense pas que les autres solutions existantes soient aujourd’hui exemptes de bug. En tout cas je regarde toujours ce qui se passe à coté et j’espère bien que tout ou tard la compétition renaitra pour motiver encore plus l’équipe Maven.

Rating: 6.3/10 (4 votes cast)

Domptez vos versions

Arnaud Héritier — Tue, 20 Apr 2010 13:14:41 +0000

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.

Abracadabra, de version tu changeras !

Le fait que Maven considère que dans un projet tout module doive pouvoir être construit indépendamment des autres, toutes les références internes (héritages, dépendances, …) répètent inlassablement le numéro de version du projet. Il existe bien des palliatifs comme utiliser la propriété ${project.version} pour ne pas répeter cette information au niveau des dépendances. Pourtant cela ne fonctionne pas au niveau de l’héritage car on retombe sur le problème de la poule et de l’oeuf. Si ma version n’est que dans le pom parent de mon projet, comment mon module va trouver son parent sans connaitre sa version ?

Cela crée donc souvent la panique à bord dans l’équipe projet lorsque pour une raison X ou Y il est nécessaire de changer la version en cours de développement. Les plus geek sortiront des commandes find, sed ou autre mais cela n’est pas toujours sans erreurs surtout si l’on a la malchance d’avoir notre numéro de version à remplacer utilisé par ailleurs (dans une dépendances externe par exemple).

Le plugin versions propose donc le mojo:set pour simplifier cette opération.

versions:set Sets the current projects version, updating the details of any child modules as necessary.

Il suffit de passer en paramètre la nouvelle version à utiliser pour que le plugin remplace partout (héritage, dépendances, …) l’ancienne valeur par la nouvelle.

mvn versions:set -DnewVersion=1.2.3-SNAPSHOT

Mais que faire si l’on avoulu faire la modification à la main et que l’on s’est planté ? Si par exemple la chaine d’héritage est rompue au sein de vos modules vous risquez de vous retrouver avec ce genre d’erreur (C’est promis on à amélioré la qualité des erreurs remontées dans Maven 3) :

[INFO] Scanning for projects... [INFO] ------------------------------------------------------------------------ [ERROR] FATAL ERROR [INFO] ------------------------------------------------------------------------ [INFO] Error building POM (may not be this project's POM). Project ID: com.foo.bar:bar-child:jar:null Reason: Cannot find parent: com.foo.bar:bar for project: com.foo.bar:bar-child:jar:null

Une fois de plus le plugin versions vient à vote secours avec le mojo versions:update-child-modules

versions:update-child-modules Scans the current projects child modules, updating the versions of any which use the current project to the version of the current project.

Lancez la commande mvn -N versions:update-child-modules et votre soucis se sera envolé (attention à ne pas oublier l’option -N car sinon maven essaiera de résoudre vos modules et il echouera à cause du problème).

Références :

Boule de cristal : Dis-moi si j’utilise les dernières versions de mes dépendances ou plugins ?

Tôt ou tard dans la vie d’un projet se pose la question de savoir si nous utilisons des versions récentes des plugins Maven ou des dépendances. Cela peut être suite à la découverte d’un bug, ou alors tout simplement pour essayer de rester à jour afin de conserver un support actif sur des livrables open-sources par exemple (essayez donc de demander à un véritable développeur open-source – qui le fait de bon coeur sur son temps libre – de corriger un bug et livrer un correctif sur une version
qui a plusieurs années !!). Le nombre important de plugins et de dépendances rentrant en compte dans un projet est vite faramineux et cette tâche devient vite une peine si l’on doit aller consulter un à un tous les sites web impartis ou si l’on doit rechercher ou naviguer dans le repository central Maven pour identifier les mises à jour.

Pour répondre à ce besoin le plugin versions fournit une série de mojo qui vont automatiquement analyser les plugins et dépendances que vous utilisez pour comparer vos versions actuelles avec celles disponibles sur les référentiels d’artifacts que vous avez déclaré dans votre projet ou paramètres utilisateurs. Le plugin vous permet de visualiser le résultat soit sous la forme d’un rapport en ligne de commande (versions:display-dependency-updates, versions:display-plugin-updates) soit dans le site web du projet généré par Maven (versions:display-dependency-report, versions:display-plugin-report). Cela fonctione aussi si vous avez stocké vos numéros de versions dans des propriétés (versions:display-property-updates, versions:property-updates-report).

versions:display-dependency-updates Displays all dependencies that have newer versions available. versions:dependency-updates-report Generates a report of available updates for the dependencies of a project. versions:display-plugin-updates Displays all plugins that have newer versions available. versions:plugin-updates-report Generates a report of available updates for the dependencies of a project. versions:display-property-updates Sets properties to the latest versions of specific artifacts. versions:property-updates-report Generates a report of available updates for properties of a project which are linked to the dependencies and/or plugins of a project.

Exemple de rapport en ligne de commande pour les mises à jour de dépendances :

[INFO] --- versions-maven-plugin:1.1:display-dependency-updates (default-cli) @ maven-my-plugin --- [INFO] The following dependencies in Dependencies are using the newest version: [INFO] org.apache.maven:maven-core .................................... 2.2.1 [INFO] org.apache.maven:maven-toolchain ................................. 1.0 [INFO] org.apache.maven.shared:maven-common-artifact-filters ............ 1.2 [INFO] plexus:plexus-utils ............................................ 1.0.1 [INFO] rhino:js ....................................................... 1.7R1 [INFO] [INFO] The following dependencies in Dependencies have newer versions: [INFO] org.apache.maven:maven-artifact ................. 2.2.1 -> 3.0-alpha-7 [INFO] org.apache.maven:maven-plugin-api ............... 2.2.1 -> 3.0-alpha-7

Exemple de rapport intégré dans le site web maven pour les mises à jour de dépendances :

Vous noterez que ce rapport est bien plus complet et vous permet de facilement identifier les dernières versions majeurs, mineurs,correctives disponibles. Je vous conseille de configurer le plugin pour utiliser la méthode de comparaison "Mercury" (celle de maven 3) plutot que la version par defaut (celle de maven 2) pour obtenir des résultats plus judicieux sur certaines librairies qui ont publié des livrables avec des versions exotiques.

Autre chose très utile, le rapport sur les mises à jour de plugin vous alerte si les versions des plugins utilisés ne sont pas définies dans votre projet (ce qui est une mauvaise pratique Maven puisque vous risquez d’avoir une mise à jour qui détériore votre build.

[INFO] [versions:display-plugin-updates] [INFO] [INFO] The following plugin updates are available: [INFO] maven-checkstyle-plugin .................................. 2.1 -> 2.2 [INFO] maven-clean-plugin ....................................... 2.1 -> 2.2 [INFO] maven-deploy-plugin ...................................... 2.3 -> 2.4 [INFO] maven-javadoc-plugin ..................................... 2.4 -> 2.5 [INFO] maven-site-plugin .......................... 2.0-beta-6 -> 2.0-beta-7 [INFO] [WARNING] The following plugins do not have their version specified: [WARNING] maven-compiler-plugin ..................... (from super-pom) 2.0.2 [WARNING] maven-deploy-plugin ......................... (from super-pom) 2.3 [WARNING] maven-install-plugin ........................ (from super-pom) 2.2 [WARNING] maven-javadoc-plugin ........................ (from super-pom) 2.4 [WARNING] maven-site-plugin .................... (from super-pom) 2.0-beta-6 [WARNING] org.codehaus.mojo:build-helper-maven-plugin .................. 1.2

Exemple de rapport sur les mises à jour de propriétés qui contiennent des versions :

[INFO] [versions:display-property-updates] [INFO] [INFO] The following version property updates are available: [INFO] ${doxiaVersion} ........................................ 1.0 -> 1.1.1 [INFO] ${doxia-sitetoolsVersion} .............................. 1.0 -> 1.1.1

Références :

Je suis ton père !

Avec le mécanisme d’héritage des descripteurs de projets, il est simple de mettre en place des descripteurs parents au niveau d’une entreprise, d’une forge ou simplement de plsuieurs projets pour partager un certain nombre de paramètres communs. Ces descripteurs ont leur propre cycle de vie, mais il est souvent conseillé d’utiliser la dernière version disponible. Au lieu d’aller voir manuellement quelle est la dernière version disponible il suffit d’appeler la commande versions:update-parent

Exemple :

[INFO] [versions:update-parent] ... [INFO] artifact org.codehaus.mojo:mojo: checking for updates from codehaus.org [INFO] artifact org.codehaus.mojo:mojo: checking for updates from central [INFO] Updating parent from 14 to 17

Cela ne vous évitera pas cependant d’aller chercher la release note associée à la nouvelle version pour comprendre les impacts espérés (ou non) sur votre build.

Vous pouvez aussi préciser un intervalle pour la mise à jour :

mvn versions:update-parent -DparentVersion="[14,16)"

Et même autoriser les SNAPSHOTs :

mvn versions:update-parent -DallowSnapshots=true

Références :

Maitrisez le chaos !

Le concept de versions dans Maven propose deux types de versions qui ne sont pas stables dans le temps :

Les SNAPSHOTs : Elles représentent les projets en cours de développement. Les livrables avec des versions dites SNASPHOT sont régulièrement actualisées par Maven (une fois par jour par défaut). Ces livrables sont stockés avec un identifiant unique lorsqu’ils sont déployés sur un référentiel distant.
Les ranges : Ce sont des intervals de versions. Au lieu de dire que l’on veut une version donnée d’un livrable, on laisse le choix à maven de choisir la version la plus récente dans un ensemble prédéfini.

Le principale problème en utilisant ces types de versions dans votre projet c’est que du jour au lendemain Maven peut les mettre à jour et que cela peut entrainer des régressions. Pour l’éviter il est utile de pouvoir figer ces versions soit en définissant exactement avec leurs identifiants uniques les SNASPHOTs que l’on utilise, soit en choisissant les versions aujourd’hui utilisées dans les intervales (ranges).

Pour cela le plugin versions propose les mojos versions:lock-snapshots, versions:unlock-snapshots et versions:resolve-ranges qui vous permettent d’éditer ces versions.

versions:lock-snapshots Attempts to resolve unlocked snapshot dependency versions to the locked timestamp versions used in the build. For example, an unlocked snapshot version like '1.0-SNAPSHOT' could be resolved to '1.0-20090128.202731-1'. If a timestamped snapshot is not available, then the version will remained unchanged. This would be the case if the dependency is only available in the local repository and not in a remote snapshot repository. versions:unlock-snapshots Attempts to resolve unlocked snapshot dependency versions to the locked timestamp versions used in the build. For example, an unlocked snapshot version like '1.0-SNAPSHOT' could be resolved to '1.0-20090128.202731-1'. If a timestamped snapshot is not available, then the version will remained unchanged. This would be the case if the dependency is only available in the local repository and not in a remote snapshot repository. versions:resolve-ranges Attempts to resolve dependency version ranges to the specific version being used in the build. For example a version range of '[1.0, 1.2)' would be resolved to the specific version currently in use '1.1'.

Vous y trouverez aussi des options pour inclures ou exclures certaines dépendances afin de cibler vos mises à jour.

mvn versions:lock-snapshots -Dincludes=org.codehaus.plexus:*,junit:junit

Références :

Mettez à jour ce que vous voulez !

Pour terminer le plugin mojo offre toute une série de mojos pour mettre à jour vos dépendances vers les versions suivantes ou les toutes dernières versions. On peu utiliser soit la prochaine version release ou snapshot. On peut aussi controler/filtrer les dépendances à mettre à jour.

versions:update-properties Sets properties to the latest versions of specific artifacts. versions:use-latest-releases Replaces any release versions with the latest release version. versions:use-latest-snapshots Replaces any release versions with the latest snapshot version (if it has been deployed). versions:use-latest-versions Replaces any version with the latest version. versions:use-next-releases Replaces any release versions with the next release version (if it has been released). versions:use-next-snapshots Replaces any release versions with the next snapshot version (if it has been deployed). versions:use-next-versions Replaces any version with the latest version. versions:use-releases Replaces any -SNAPSHOT versions with the corresponding release version (if it has been released).

Références :

Oopps !!!!

Même si une large partie des projets sont supposés être gérés dans un gestionaire de versions de sources, le plugin versions intègre par défaut sont propre système de validation/annulation pour toutes les opérations dans lesquelles il modifie vos descripteurs de projets. Pour cela il crée des copies de sauvegarde de vos descripteurs. Vous pouvez alors les supprimer (et donc valider ses changements) avec la commande versions:commit, ou vous pouvez tout annuler avec versions:revert. ATTENTION, cette sauvegarde ne gère pas d’historique. Elle ne conserve que la dernière modification. Pensez à valider ou rejeter vos changements après chaque modification.

versions:commit Removes the initial backup of the pom, thereby accepting the changes. versions:revert Restores the pom from the initial backup.

Références :

Rating: 9.0/10 (7 votes cast)

RivieraJug : Le soleil, Maven et la mer

Arnaud Héritier — Sun, 18 Apr 2010 22:58:17 +0000

Mardi soir je serai à nouveau sur la route des JUGs pour m’arrêter cette fois-ci à Nice au RivieraJUG. Cette soirée se déroulera dans les locaux de l’INRIA Sophia-Antipolis.

La soirée devait être, il y a encore quelques minutes, une présentation de Maven par votre humble serviteur et de Gradle par Hans Dockter son créateur. Malheureusement il vient de nous informer que le dernier vol qu’il avait pu prévoir pour venir venait d’être annulé (cochonnerie de nuage).
Il pourrait toujours être drôle que je fasse moi-même la présentation Gradle mais je ne le connais pas encore assez pour pouvoir en parler et m’en moquer. On va donc se contenter de faire la fête à Maven !.
En fonction de vos envies et de vos connaissances j’adapterai le contenu pour vous parler de Maven, son ecosystème, son avenir. Nous pourrons aussi passer en revue les diverses bonnes et mauvaises pratiques que j’ai pu voir.
Je vous dis donc à mardi soir. Venez nombreux et n’oubliez surtout pas de vous inscrire !!

MAJ 25 avril 2010 : Les slides de la session

Rating: 7.5/10 (2 votes cast)

Build partiel avec Maven : Construire moins pour aller plus vite.

Arnaud Héritier — Sun, 18 Apr 2010 20:05:00 +0000

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.

Le projet exemple

Pour illustrer l’article je prend volontairement un projet simple sans complexité dans les dépendances entre les modules.
Ce projet est composé de 6 sous-modules (A à F) avec les dépendances suivantes

Module F dépend de Module E,
Module E dépend de Module D,
Module D dépend de Module C,
Module C dépend de Module B,
Module B dépend de Module A.

Dans cet article j’utilise le verbe « construire » pour nommer une exécution Maven sur un module/projet mais il faut se rappeler que Maven fait bien plus que cela nativement : exécution des tests, génération de site web, etc. Ces options s’appliquent à n’importe quelle phase ou plugin que l’on souhaite appeler sur le projet.

A noter que les commandes Maven doivent être impérativement appelées depuis le projet principal où sont déclarés tous les modules afin qu’il connaisse le graphe complet de l’exécution des modules et n’extrait que les parties qui vous intéressent.
Dans notre exemple, compte tenu des dépendances entre modules, une exécution complète de Maven va suivre l’ordre alphabétique.
arnaud@mbp-arnaud:~$ mvn install [INFO] ------------------------------------------------ [INFO] Reactor Summary: [INFO] [INFO] Project ....................... SUCCESS [2.132s] [INFO] ModuleA ....................... SUCCESS [5.574s] [INFO] ModuleB ....................... SUCCESS [0.455s] [INFO] ModuleC ....................... SUCCESS [0.396s] [INFO] ModuleD ....................... SUCCESS [0.462s] [INFO] ModuleE ....................... SUCCESS [0.723s] [INFO] ModuleF ....................... SUCCESS [0.404s] [INFO]

Sélectionner les modules à construire. L’option -pl.

arnaud@mbp-arnaud:~$ mvn --help usage: mvn [options] [] [] Options: ... -pl,--projects Build specified reactor projects instead of all projects ...
Cette option permet de choisir spécifiquement les modules du projet à construire. Cela évite de naviguer de répertoire en répertoire pour lancer chaque module ou d’utiliser plusieurs lancements successifs avec l’option « -f chemin_vers_un_pom.xml ». Cela vous fait gagner aussi du temps en évitant de charger Maven et la JVM plusieurs fois. Enfin le fait que Maven utilise son « reactor », c’est lui qui ordonne les modules en fonctions des dépendances et ça n’est pas à vous de faire ce calcule.
La liste de modules est séparée par des virgules. Pour identifier chaque module, nous pouvons soit utiliser son chemin relatif par rapport à la racine du projet soit son artifactId.

arnaud@mbp-arnaud:~$ mvn install –pl moduleE,moduleB [INFO] ------------------------------------------- [INFO] Reactor Summary: [INFO] [INFO] ModuleB .................. SUCCESS [2.774s] [INFO] ModuleE .................. SUCCESS [1.008s] [INFO]
Dans note exemple nous demandons à Maven d’executer le cycle de vie jusqu’à la phase « install » pour les modules E et B. Maven calcule automatiquement l’ordre et construits le module B puis le module E.

Construire tous les modules impactant la construction d’une liste de modules. L’option -am

arnaud@mbp-arnaud:~$ mvn --help usage: mvn [options] [] [] Options: -am,--also-make If project list is specified, also build projects required by the list ...
Cette option s’utilise conjointement à l’option -pl. En plus de construire les modules demandés par l’option -pl, Maven va construire tous les modules nécessaires à ceux-ci (donc ceux qui apparaissent dans leurs dépendances).

arnaud@mbp-arnaud:~$ mvn install –pl moduleD -am [INFO] ------------------------------------------ [INFO] Reactor Summary: [INFO] [INFO] ModuleA ................. SUCCESS [4.075s] [INFO] ModuleB ................. SUCCESS [0.468s] [INFO] ModuleC ................. SUCCESS [0.354s] [INFO] ModuleD ................. SUCCESS [0.384s] [INFO]
Cas d’usage : Imaginons que vous développiez une application JEE avec de nombreux JARs, quelques WARs et EARs. Si vous travaillez sur un war en particulier et que vous êtes capable de ne déployer que ce dernier pour tester vos développements, vous n’avez pas besoin de reconstruire tout votre projet. Demandez à Maven de reconstruire que les modules nécessaires à la construction du WAR en passant ce dernier en paramètre de l’option -pl et en ajoutant l’option -am.
mvn install –pl monWAR -am

Construire tous les modules impactés par la construction d’une liste de module. L’option -amd

arnaud@mbp-arnaud:~$ mvn --help usage: mvn [options] [] [] Options: ... -amd,--also-make-dependents If project list is specified, also build projects that depend on projects on the list ...
Cette option s’utilise conjointement à l’option -pl. En plus de construire les modules demandés par l’option -pl, Maven va construire tous les modules qui dépendent de ces derniers.

arnaud@mbp-arnaud:~$ mvn install –pl moduleD -amd [INFO] ------------------------------------------ [INFO] Reactor Summary: [INFO] [INFO] ModuleD ................. SUCCESS [4.881s] [INFO] ModuleE ................. SUCCESS [0.478s] [INFO] ModuleF ................. SUCCESS [0.427s] [INFO]
Cas d’usage : Vous travaillez sur un module et vous voulez vérifier que vos modifications n’impactent pas les autres modules qui l’utilisent. Vous demandez donc à Maven de reconstruire ce module (-pl monModule) et tous ceux qui l’utilisent (-amd). Ainsi la compilation et les tests des autres modules valideront vos changements.
mvn install –pl monModule -amd

Reprennez où vous voulez. L’option -rf

arnaud@mbp-arnaud:~$ mvn --help usage: mvn [options] [@lt;goal (s)>] [] Options: ... -rf,--resume-from Resume reactor from specified project ...
Cette option permet de reprendre à un point donné (un module) l’ensemble de la construction du projet. Tout comme l’option -pl, le module passé en paramètre de l’option -rf est identifié à partir de son chemin relatif ou de son artifactId.

arnaud@mbp-arnaud:~$ mvn install –rf moduleD [INFO] ------------------------------------------ [INFO] Reactor Summary: [INFO] [INFO] ModuleD ................. SUCCESS [9.707s] [INFO] ModuleE ................. SUCCESS [0.625s] [INFO] ModuleF ................. SUCCESS [0.679s] [INFO] Project ................. SUCCESS [2.467s] [INFO]
Cas d’usage : Vous travaillez sur votre projet et vous voulez le reconstruire entièrement pour valider vos changements. Vous lancez la construction et elle échoue dans le module D. Vous trouvez le problème et corrigez le module D erroné. A quoi bon relancer la construction complète alors que vous savez que les modules construits avant le module D n’ont pas été modifiés et ne peuvent pas être affecté par votre modification. Vous demandez donc à Maven de relancer toute la construction à partir du module D.
mvn install –rf moduleD

Rating: 9.8/10 (6 votes cast)

En manque de chocolat …

Arnaud Héritier — Tue, 06 Apr 2010 21:14:47 +0000

… je n’ai pas d’autre choix que de retourner en Suisse me réapprovisionner.
Après les sessions à l’AlpesJUG et GenevaJUG de la semaine dernière, je m’en retourne ce jeudi soir à Lausanne présenter Maven en général et sa troisième version majeure en particulier.

Comme de coutume j’ai bien plus de slides et de contenu que le temps imparti. J’essaierai donc de spécialiser la session en fonction des attentes de l’auditoire présent.
Au menu nous pourrons aborder différents thèmes comme :

Son histoire, un tour d’horizon du produit, ses différentes fonctionnalités et son positionnement par rapport à la concurrence,
Son ecosystem, comme les gestionnaires de référentiels de binaires, les serveurs d’intégration continue, les tableaux de bord qualité, l’IDE,
Les bonnes et mauvaises pratiques d’utilisation,
Quelques cas d’usages méconnus (sécurisation des passwords, release d’un projet, options du réacteur),
Retour vers le futur, que nous réserve Maven 3.x.

N’oubliez pas de vous inscrire et rejoignez-nous nombreux !!

MAJ 13 Avril 2010 : Voici les slides de la présentation. Une fois de plus ceux-ci ont été mis à jour depuis la précédente présentation à Genève.

Rating: 10.0/10 (1 vote cast)

3Moopydelfy passe à la vitesse supérieure

Arnaud Héritier — Sat, 03 Apr 2010 08:40:20 +0000

@3Moopydelfy, super maman blogueuse sur le net, et ma femme à la ville, entame une nouvelle aventure en ouvrant un second blog.

Vous retrouverez désormais sur son premier blog Bonbon Bisous tout le contenu orienté super-maman, avec par exemple les loisirs pour enfants, ou la cuisine. Ce blog orienté « famille » devrait intéresser en priorité les papas et mamans que vous pouvez être au quotidien.

Sur son nouveau blog New Kids On The Geek vous retrouverez son coté super-femme ou elle parlera de ses loisirs. Mangas, comics, séries télé ou cinéma en sont quelques-uns.

En espérant que vous y trouverez votre bonheur, au moins vous êtes certain de ne jamais trouver sur ses blogs un POM ou une ligne de commande Maven !
Bon week-end à tous !

Rating: 0.0/10 (0 votes cast)

Subversion : Exclure en masse les fichiers et répertoires générés d’un projet Maven

Arnaud Héritier — Thu, 25 Mar 2010 13:42:09 +0000

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.

Tirons parti de ces derniers pour faire cela en moins de 10 secondes.
Il suffit de créer à la racine du projet un ficher module.svn-ignore dans lequel on va lister les fichiers ou répertoires à ignorer :
.settings .project .classpath .idea *.iml *.ipr *.iws bin target
Et ensuite de lancer la commande :
find . -name pom.xml -exec dirname {} \; | xargs svn ps svn:ignore -F module.svn-ignore
Il ne vous reste plus qu’à publier (commit) vos changements sur le serveur subversion et le tour est joué.

Plus de détails ?
Dans le fichier d’exclusions je choisis de mettre

le répertoire target de maven,
le répertoire bin souvent (toujours ?) utilisé par m2eclipse
le répertoire .settings et les fichiers .project , .classpath pour les utilisateurs d’eclipse.
le répertoire .idea et les fichiers *.iml, *.iws, *.ipr pour les utilisateurs d’IntelliJ Idea

Le script recherche ensuite tous les descripteurs de projets (pom.xml) et applique l’exclusion au répertoire dans lequel il se trouve.
PS : Pour les malheureux contraints à développer sous windows, vous pouvez installer cygwin pour avoir un environnement shell potable.
MAJ 27 Mars 2010 : Ajout de l’exclusion des fichiers *.iws de IntelliJ Idea (cf. commentaire de Gregory Boissinot)

Rating: 0.0/10 (0 votes cast)

Présentations Maven (3) à l’AlpesJUG et au GenevaJUG

Arnaud Héritier — Mon, 22 Mar 2010 22:25:27 +0000

La semaine prochaine je reprends ma tournée des JUGs francophones pour vous parler de Maven à Grenoble et à Genève.

Je serai, lundi soir, le 29 Mars à l’AlpesJUG, à Grenoble. L’accueil aura lieu à partir de 18H30 dans l’amphithéâtre E de l’ENSIMAG, rue de la Chimie. La conférence débutera à 19H00. La soirée se terminera par un diner au restaurant La Charbonnade, 10 Rue Marcel Porte, 38000 Grenoble (04 76 47 43 07‎). N’oubliez pas de vous inscrire pour la présentation et pour le restaurant, les places sont limitées.

Le lendemain, mardi 30 Mars je serai en Suisse au GenevaJUG. Dépéchez-vous de vous inscrire, il ne reste déjà plus que 10 places. La présentation aura lieu salle U259 à l’Uni-Dufour à partir de 18h30 et sera aussi suivi d’un diner.

Lors de ces présentations nous aborderons comment Maven intervient pour chacune de ces étapes:

le build du projet sur le poste du développeur
la gestion des dépendances et des dépôts
la mise en place de l’intégration continue
l’utilisation des métriques et des rapports de qualité
le déploiement continu

Je reviendrai aussi sur les nouveautés à attendre de Maven 3 qui sera la prochaine version majeure et qui verra le jour dans quelques mois (pas folle la guêpe, elle reste vague ).

En fonction de l’auditoire et de son niveau de connaissances sur Maven j’adapterai le contenu et la durée de la séance de questions/réponses. « C’est vous qui voyez » comme dirait Laspalès.

D’autres sessions sont dores et déjà planifiées dans plusieurs JUG, et je vous en parlerai plus en détail d’ici peu :

LausanneJUG le 8 avril,
RivieraJUG (Nice) le 20 Avril,
ParisJUG le 11 Mai,
LorraineJUG le 1 juin.

Mise à jour (23 Mars) : J’ai oublié de préciser qu’une librairie partenaire du GenevaJUG devrait proposer à la vente sur place notre livre « Apache Maven ».

Mise à jour N°2 (23 Mars) : : La salle pour l’AlpesJUG à changé. La session aura lieu dans l’amphithéâtre E de l’ENSIMAG, rue de la Chimie.

Mise à jour N°3 (30 Mars) : : Ci-dessous la présentation au AlpesJUG

Mise à jour N°4 (1 Avril) : : Ci-dessous la présentation au GenevaJUG (quelques ajouts/modifications/corrections)

et les photos.

Rating: 10.0/10 (1 vote cast)

Convertir en masse les notifications standard Hudson par celles du plugin Email-Ext

Arnaud Héritier — Fri, 19 Feb 2010 07:00:23 +0000

Chez eXo platform nous utilisons Hudson pour notre intégration continue.
La combinatoire entre les différents types de builds (intégration continue, reporting, packaging), les différents projets et leurs différentes branches de maintenance représente des dizaines de jobs dans Hudson.
Jusqu’à présent nous utilisions les notifications standards de Hudson pour recevoir les emails avec les statuts courant des jobs.
Il faut cependant avouer que celles-ci offrent très peu souplesse en ce qui concerne le contenu et les conditions de notification.

J’ai donc installé le plugin Hudson Email Extension Plugin qui est beaucoup plus paramétrable.
Après quelques tests concluant sur un nombre limité de projets, j’en viens donc au déploiement global sur l’ensemble des jobs hudson.
Et là c’est la catastrophe !!!! Hudson ne propose pas d’édition en masse de ses jobs (à part le plugin Configuration Slicing plugin mais qui ne gère qu’un nombre très restreint d’éléments de configuration).
Alors comment faire ?
Après un rapide tour sur la liste de diffusion du projet on me conseil « tout simplement » d’utiliser la capacité de modification à chaud du serveur à l’aide de sa console Groovy.
Celle-ci est effectivement bien plus puissante qu’un simple « Bulk change » puisque l’on peut accéder à l’ensemble des objets en mémoire sur le serveur (et donc à la configuration des jobs).
Le gros avantage de cette solution « codée » c’est aussi qu’elle me permet de reprendre les listes de destinataires utilisées par le mécanisme de notification standard afin de les injecter dans la nouvelle configuration.

Ce script execute donc pour chaque job les étapes suivantes :

Si le job est de type Maven alors j’enregistre la liste de destinataires depuis le « reporter » et je le retire du job.
Dans tous les cas je regarde les « publishers » actuels et si il y a les notifications standards ou du plugin mail-ext j’enregistre la liste de destinataires (donc la liste de mail-ext écrase celle de la notification standard si elle existait qui elle même écrase celle de maven si elle existait) et je retire le ou les « publishers ».
Je crée et rajoute au job mon nouveau « publisher » mail-ext configuré selon mes besoins.

J’ai ainsi pu mettre à jour tous les jobs de mon serveur sans erreur et sans tâche manuelle fastidieuse.

Ci dessous le script groovy (n’étant ni expert en groovy et encore moins dans les APIs d’Hudson que je découvre, ce code doit être facilement améliorable).

import hudson.plugins.emailext.*
import hudson.plugins.emailext.plugins.trigger.*
import hudson.plugins.jira.*
import hudson.model.*
import hudson.maven.*
import hudson.maven.reporters.*
import hudson.tasks.*

// For each project
for(item in Hudson.instance.items) {
  def recipients
  println("JOB : "+item.name);

  // Find current recipients defined in project

  if(item instanceof MavenModuleSet) {
    println(">MAVEN MODULE SET");

    // Search for Maven Mailer Reporter
    println(">>Reporters");
    for(reporter in item.reporters) {
      println(">>> "+reporter);
      if(reporter instanceof MavenMailer) {
        recipients = reporter.recipients
        // remove it
        item.reporters.remove(reporter)
      }
    }
  } else
  if(item instanceof FreeStyleProject) {
    println(">FREESTYLE PROJECT");
  }

  println(">>Publishers");
  for(publisher in item.publishersList) {
    println(">>> "+publisher);
    // Search for default Mailer Publisher
    if(publisher instanceof Mailer) {
      recipients = publisher.recipients
      // remove it
      item.publishersList.remove(publisher)
    } else
    // Or for Extended Email Publisher
    if(publisher instanceof ExtendedEmailPublisher) {
      recipients = publisher.recipientList
      item.publishers.remove(publisher)
      // remove it
      item.publishersList.remove(publisher)
    }
  }

  // If we found recipients list to send mail
  if(recipients!=null){
    println (">CURRENT RECIPIENT : "+recipients)
    // We create a new Extended Email Publisher
    def eep = new ExtendedEmailPublisher();
    eep.recipientList = recipients
    eep.defaultSubject = "\$DEFAULT_SUBJECT"
    eep.defaultContent = "\$DEFAULT_CONTENT"
    // With some triggers
    eep.configuredTriggers.add(new FailureTrigger(
      email : new EmailType(sendToRecipientList : true,
        body : ExtendedEmailPublisher.PROJECT_DEFAULT_BODY_TEXT,
        subject : ExtendedEmailPublisher.PROJECT_DEFAULT_SUBJECT_TEXT )))
    eep.configuredTriggers.add(new FixedTrigger(
      email : new EmailType(sendToRecipientList : true,
        body : ExtendedEmailPublisher.PROJECT_DEFAULT_BODY_TEXT,
        subject : ExtendedEmailPublisher.PROJECT_DEFAULT_SUBJECT_TEXT )))
    eep.configuredTriggers.add(new StillFailingTrigger(
      email : new EmailType(sendToRecipientList : true,
        body : ExtendedEmailPublisher.PROJECT_DEFAULT_BODY_TEXT,
        subject : ExtendedEmailPublisher.PROJECT_DEFAULT_SUBJECT_TEXT )))
    eep.configuredTriggers.add(new StillUnstableTrigger(
      email : new EmailType(sendToRecipientList : true,
        body : ExtendedEmailPublisher.PROJECT_DEFAULT_BODY_TEXT,
        subject : ExtendedEmailPublisher.PROJECT_DEFAULT_SUBJECT_TEXT )))
    eep.configuredTriggers.add(new UnstableTrigger(
      email : new EmailType(sendToRecipientList : true,
         body : ExtendedEmailPublisher.PROJECT_DEFAULT_BODY_TEXT,
        subject : ExtendedEmailPublisher.PROJECT_DEFAULT_SUBJECT_TEXT )))
    // And we add/replace it in the project
    item.publishersList.replace(eep);
  }else{
    println (">NO RECIPIENT")
  }

  println("\n=======\n");
}

Rating: 8.0/10 (1 vote cast)