aheritier.net » Apache Maven

Clone all repositories from a github organization

Arnaud Héritier — Tue, 17 Jan 2012 22:42:47 +0000

Tomorrow I will attend the first Hackergarten at Paris.
This is an event where active open-source committers can met potential contributors and help them to submit a (first) contribution.
I’ll be here to help those who would like to contribute on JenkinsCI and Apache Maven.
To prepare this event I wanted to prepare a checkout of all sources and a local repository with all required dependencies to avoid to see contributors losing their time by downloading the earth with Maven or checking out Subversion (and to not be blocked if we had some network issues).
For Maven which is hosted on Subversion it is long but easy because we have a special SVN directory using svn:externals to checkout all trunks in one step : https://svn.apache.org/repos/asf/maven/trunks/
But for Jenkins with several thousands of plugins and thus git repositories it is less easy to clone all of them.
I saw that there was everything needed in github APIs but it was late and I didn’t want to start to write a new script (One teacher told me a long long time ago that it was a quality to be idle – do it with less and less you’ll have to maintain).
I asked on jenkinsci IRC channel and thanks to Jørgen P. Tjernø I had my reply quickly.
With Ruby 1.8 (default version on Macos) :
sudo gem install json curl -s https://github.com/api/v2/json/repos/show/jenkinsci | ruby -rubygems -e 'require "json"; JSON.load(STDIN.read)["repositories"].each {|repo| %x[git clone #{repo["url"]} }'
With Ruby 1.9+, the json library is by default thus you just use :
curl -s https://github.com/api/v2/json/repos/show/jenkinsci | ruby -rjson -e 'JSON.load(STDIN.read)["repositories"].each {|repo| %x[git clone #{repo["url"]} }'
With that I’m able to clone all repositories from jenkinsci github organization.
Tomorrow I’ll just have to launch a command like this to download all dependencies :
find . -name pom.xml -maxdepth 2 -exec mvn -f {} -Dmaven.repo.local=./maven-local-repo dependency:go-offline \;
Update : As there are more than 30 repositories in JenkinsCI Github organization, I had to call the clone command several times by adding ?page=X (X=2,..) after the url https://github.com/api/v2/json/repos/show/jenkinsci to grab all results pages.

Rating: 0.0/10 (0 votes cast)

Graven – The best of Apache Maven and Gradle

Arnaud Héritier — Fri, 07 Oct 2011 16:24:09 +0000

I’m back !!! I have a lot of things to share and I would like to restart this blog in english. I don’t yet know which frequency of publication I’ll be able to have but I will do my best to keep this blog alive.
To start I wanted to share with you something we developed few months ago with Gregory Boissinot (@gboissinot). While we were traveling everywhere in France to show Maven and Gradle in various Java User Groups we had a strange idea : “And if we tried to do a new tool taking the best of Gradle and Apache Maven”. While we had a lot of train we started to develop it and Graven was born. For now it is only at early stage of development but you’ll find below a quick demo of it. I hope you’ll enjoy.

Ok, nothing is perfect and we may have to improve few things but isn’t it a good start ?
As we love OpenSource spirit, we published our work on Github. Feel free to contribute.

Rating: 8.5/10 (2 votes cast)

Maven : How mojo executions are ordered in a phase

Arnaud Héritier — Fri, 14 Jan 2011 23:10:52 +0000

Note that I’m switching to english for this blog entry but I’m not yet sure it will be always the case … I’m testing
After reporting a regression in M2 -> M3 upgrade (see MNG-4975) I discovered I didn’t understood how is computed the execution order of mojos in a Maven phase (Thanks Benjamin Bentmann).

As you know Maven is built around the notion of build lifecycle. You call a maven phase in your project and Maven will execute all phases to go up to the one you asked. For each phase it will execute a set of Mojos bound on it.
The question is what happens if several mojos (from the same or different plugins) are bound to the same phase. In which order are they executed ?
The reply is : in the order of declaration in the POM. Thus the important thing to understand is that the id used for an execution to bind a mojo to a phase isn’t used to compute this order.
And what about inheritance ? Executions of the parent are done before the child executions.
Our team will add a clear documentation about this in plugins configuration documentation. What is important to understand it is that there is no magic in Maven (just few holes in the documentation and we are doing our best to fill them).

Rating: 6.5/10 (2 votes cast)

Soirée build au Lyon JUG

Arnaud Héritier — Mon, 22 Nov 2010 10:09:50 +0000

Ce mardi soir je serai au LyonJUG pour une soirée build.
La soirée commencera à 19h et aura lieu à l’EPITECH.

En première partie de soirée Grégory Boissinot de Zénika (sponsor de la soirée, merci à eux) vous montrera comment Gradle révolutionera l’avenir du build … ( ou pas )

Pour ma part, dans la seconde partie, je me concentrerai sur Maven 3. Je vous ferai découvrir ce que la toute nouvelle version 3.0 peut déjà vous apporter aujourd’hui (La 3.0.1 sera très bientôt dans tous les bacs !) et ce que les prochaines versions 3.x vont apporter dans l’année qui vient.

A demain et n’oubliez surtout pas de vous inscrire !

Rating: 7.0/10 (3 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)

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.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)

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