aheritier.net » Java

Paris JUG – 3 ans déjà !!!

Arnaud Héritier — Thu, 17 Feb 2011 05:00:19 +0000

Comme il a bien grandit le bébé. 3 ans déjà qu’est né le Paris JUG.
Ses parents, Antonio Goncalves et David Dewalle s’en sont bien occupés et ont trouvé une aide précieuse auprès de Zouheir Cadi pour finir par former un mini équipe commando (Nicolas Martignole, Claude Falguière, …).
Pour fêter cet évenement et remercier ses organisateurs qui ont fait le renouveau de la communauté Java en France une soirée exceptionnelle est organisée le Lundi 28 février. Elle commencera de 18h00 à 22h15 dans les locaux de la Cité Universitaire Internationale, avec des sessions sur le thème “Siffler en travaillant”.
Cela sera suivit par une “surprise” puis un diner au Vavin et vous pourrez terminer la nuit au Falstaff.
(Compte tenu du programme de la soirée si vous venez en voiture, garez plutot du coté de Montparnasse et rejoignez la Cité Universitaire Internationale en transports. Le retour sera organisé par le JUG).
J’ai une fois de plus la grande malchance de ne pas pouvoir y venir, étant à l’autre bout du monde avec les équipes Vietnamienne d’eXo alors profitez-en pour moi !! (ne me plaignez pas, je vous rassure c’est que du bonheur aussi )
La soirée promet d’être somptueuse. N’oubliez surtout pas de vous inscrire pour la soirée, la surprise et le restaurant (inscriptions ouvertes dans quelques jours).
Retrouvez comme d’habitude le programme détaillé de la soirée sur le site du ParisJUG.

Rating: 0.0/10 (0 votes cast)

Séance Dédicace à la librairie Le Monde en Tique

Arnaud Héritier — Wed, 20 Oct 2010 05:00:03 +0000

Roulements de tambours, faites sonner les trompettes, je sors de chez moi
Ce samedi 23 octobre de 15h à 18h je serai à la librairie Le Monde en Tique pour une séance dédicace EXCEPTIONNELLE !!
Bien sur vous pourrez y retrouver mon livre Apache Maven aux éditions Pearson, mais je sais que vous l’avez déjà tous sous votre oreiller.
Alors je n’y serai pas seul. Je serai accompagné par deux pointures, que dis-je ! Deux monstres sacrés de la communauté Java francophone.

Le premier n’est autre qu’Emmanuel Bernard, surnommé “Chuck Norris” ! Cependant ses amis ont plutôt tendance à l’appeler l’homme aux mitaines depuis les révélations qu’il a pu faire dans le podcast Les CastCodeurs qu’il a crée l’année dernière. Contributeur OpenSource depuis les origines du monde il a fortement contribué à Hibernate et se consacre aujourd’hui à Hibernate Search pour lequel il a publié un ouvrage : Hibernate Search in Action aux éditions Manning.

Mon deuxième compère est une figure de la communauté Java Francophone. C’est à lui que l’on doit la revolution des Java User Group en France qui se sont sont mis à fleurir après qu’il ait lancé l’instance parisienne qui accueille désormais 200 personnes chaque mois. Il participa à travers le JCP (JSR 316, JSR 317, JSR 318) à la création de JEE6 qu’il vous décrit, dissect, explique dans son ouvrage Java EE 6 aux éditions Apress qui en est déjà à sa seconde édition. Dans un tout autre registre il nous a promis de faire sur place une démonstration de ses talents de danseur avec entorse à la clef.

Alors si vous voulez venir discuter avec nous, manger quelques petits gateaux ou encore rencontrer les pom-pom girls qu’Antonio nous a promis, rejoignez nous ce samedi 23 octobre de 15h à 18h à la librairie Le Monde en Tique (6 Rue Maître Albert, 75005 Paris).
Nous ne ferons pas de discrimination. Nous accepterons de discuter même avec ceux qui ne font pas du Java et qui n’ont pas acheté nos 3 livres.

View Larger Map

Un invité mystère pourrait être présent ce jour là et dans ce cas vous pourriez avoir des copies de mon livre d’une valeur unique

Rating: 0.0/10 (0 votes 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.6/10 (5 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)

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.9/10 (9 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)

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.

Mise à jour N°5 (7 Avril) : : Une superbe retranscription de ma session au GenevaJUG pour tous ceux qui n’ont pas eu la chance d’avoir pu venir : http://waves.inagua.ch/2010/04/06/3e-geneva-jug-maven/

Rating: 10.0/10 (1 vote cast)

Maven Release Plugin 2.0

Arnaud Héritier — Thu, 11 Feb 2010 02:00:59 +0000

Après 9 beta la version 2.0 du plugin release est enfin disponible. Les derniers coups de tournevis apportés à ce dernier devraient en ravir plus d’un !!

Le plug-in supporte désormais les projets en structure “flat” ou aussi nommée “en râteau”. Pour ces projets ( pour diverses bonnes ou moins bonnes raisons ) le POM parent n’est pas en même temps le réacteur des sous modules. Le parent est un sous-module à part entière. Jusqu’à présent le plug-in release ne fonctionnait pas sur ce type de projet. C’est enfin une chose corrigée.
Les bugs les plus récalcitrants du goal branch sont corrigés. Vous pouvez utiliser ce dernier par exemple pour créer une branche depuis le trunk avant de faire la release pour passer sur une branche dite de stabilisation. Ou alors vous pouvez créer la branche depuis un tag pour créer une branche de maintenance de la version en question. Dans tous les cas le plugin prend en charge la modification des versions dans les POMs, chose que l’on sait bien ennuyeuse (et dangereuse) à faire à la main.
Le plug-in release contrôle à nouveau correctement les modifications locales (fichiers modifiés ou ajoutés et non commités) avant de démarrer le processus de release ou de création d’une branche. Cette fonctionnalité était buggée depuis la version 2.0-beta-8 (cf. MRELEASE-481).
Enfin, je pense qu’il s’agit de la correction la plus attendue de tous : Il n’est plus nécessaire pendant la phase de préparation d’installer les artifacts du projet dans le repository local. A l’origine, lié à un problème dans le noyau de Maven, Il était très souvent nécessaire de configurer le goal prepare du plugin pour faire une installation des artifacts plutot qu’une vérification sans quoi la release échouait faute de trouver les dépendances entre modules. Cela avait les désavantages de couter du temps (le packaging de gros artifacts comme des WARs ou EARs prend beaucoup de temps au niveau du build à cause de l’utilisation intensive des IOs de la machine) et surtout de pouvoir produire lors de cette phase qu’une partie des binaires de la version en cours de release si cette dernière echouait. C’est pour cela que la phase prepare ne doit faire qu’exécuter les tests sans créer les binaires et si tout se passe bien c’est la phase perform qui générera ces derniers. Ceci est désormais rentré dans le bon ordre et suit l’idée d’origine du plugin (la fameuse raison des deux phases).

La documentation du plugin est à jour. Vous pouvez retrouver le détail des modifications dans la Release Note de cette version.

Bonne release à tous !!

Question aux produits concurrents : Vous faites comment pour offrir ce service à vos utilisateurs ?

Rating: 0.0/10 (0 votes cast)

N’utilisez pas Hudson 1.344 !!

Arnaud Héritier — Mon, 08 Feb 2010 07:25:24 +0000

Je vous aurai prévenu
J’ai découvert un bug bloquant (http://issues.hudson-ci.org/browse/HUDSON-5536) qui corrompt les données locales. Ainsi même un retour en arrière sur la version d’Hudson ne vous corrige pas le problème. La correction manuelle à faire sur les fichiers Hudson est décrite dans l’issue Jira si par malchance vous avez déjà fait l’upgrade et que comme moi vous vous retrouvez avec tous vos builds KO.
L’équipe va probablement sortir une version 1.345 en urgence dans les heures à venir.
Merci à Andrew Bayer (@abayer sur twitter) pour son coup de main.

Rating: 0.0/10 (0 votes cast)

Et une bougie de plus !!

Arnaud Héritier — Mon, 08 Feb 2010 03:00:31 +0000

En ces temps moroses pour la communauté Java où le bulldozer Oracle écrase, petit à petit, feu SUN Microsystems, je me réjoui de voir que les Javaïstes n’ont jamais été aussi rassemblés qu’aujourd’hui !! La France n’est pas en reste de ce mouvement avec un nombre impressionnant de Java Users Groups nés en deux ans.

Ce mardi 9 février toute la communauté fêtera dignement les deux ans du père de tous les JUGs français : Le ParisJUG !!
Encore un grand bravo à toute l’équipe qui a su mener à bien cette quête qui n’a pas été facile tous les jours. Présent dès la première réunion j’avoue que c’est à chaque fois un grand bonheur de tous vous y retrouver.
Alors si vous ne savez pas encore quoi faire demain soir, ne cherchez plus !!
Le thème de la soirée sera l’open-source en France. Vous y retrouverez de nombreuses micro-sessions des acteurs de l’open-source Français : Obeo, XWiki, Développons en Java, jCaptcha, jax-doclets, Play! framework et le meilleur de tous, eXo Platform (Quoi ? Je ne suis pas objectif ? )
La keynote sera présentée par Sacha Labourey, ex-CTO de JBoss, que j’ai rencontré il y a peu (Il fait parti du Board of Advisors d’eXo Platform). C’est une personne vraiment super sympathique et très intéressante. Je vous invite sincèrement à faire sa connaissance.

Courrez immédiatement vous inscrire si ça n’est pas déjà fait car même si la salle est beaucoup plus grande que d’habitude, les places partent vites !!
Je vous conseil aussi vivement de vous inscrire pour la 3eme mi-temps (aka cocktail dinatoire), car c’est un moment privilégié pour rencontrer et discuter avec toutes les personnes de la communauté.

A mon grand regret, pour cause de déplacement professionnel, je ne pourrai pas être des vôtres puisque je suis à 9000Km de là, à Hanoï. Je suivrai cependant avec plaisir la soirée depuis la Wave Google (pour une fois que Google Wave va peut être enfin me servir à quelque chose). Pour tous ceux qui auraient eu la bonne idée d’acheter notre livre Apache Maven, sachez que Nicolas De loof, mon co-auteur, sera là et qu’il adore faire des dédicaces !!

Je terminerai en remerciant publiquement une dernière fois SUN Microsystems pour tout ce qu’ils ont pu apporter à Java. La communauté n’a pas toujours été tendre avec eux et pourtant qui aime bien châtie bien. La communauté Java n’en ressortira que plus forte et plus soudée pour se faire entendre du géant Oracle.

Signé : Le mec au simple polo fatigué, baskets, et moyennement rasé.

Rating: 0.0/10 (0 votes cast)