mvn arnaud:blog » Apache Maven

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)

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)

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)

From Apache Archiva to Sonatype Nexus

Arnaud Héritier — Tue, 09 Feb 2010 07:00:51 +0000

This article was firstly published in this blog in french in May 2009 and later in english in Sonatype Blog. I put a copy here as an archive.

As a member of the Archiva team (though rarely active, I admit) I will try to defend it throughout this article. However, being a professional consultant first and foremost, I hope to keep my objectivity. I’ll let you be the judge …

Having recently migrated a significant number of repository servers from Apache Archiva to Sonatype Nexus, I would like to share with you the process I followed, some tips, and point out a few pitfalls I encountered.
A big Thank you to Tarpoon, C’est pas dur and all of my team for helping.

Introduction

Background

A little background to this migration: We had a large enterprise-scale implementation with dozens of JEE projects of all sizes (from a mouse to the ocean liner – and NO! I am not talking about the Titanic!), and at least 200 active developers accessing the system simultaneously during the day.
Most projects are using Maven. To help teams to make better and faster builds we offered a complete infrastructure for continuous integration: a big server (Dual QuadCore Xeon with 16GB RAM running Red Hat Enterprise Linux 5.1), hosting an Atlassian Bamboo continuous integration server with (approximately): 110 (real time) continuous integration builds, 40 (daily) maven sites builds, 20 (daily) Sonar builds. It also hosted a Maven repository server (Archiva 1.1.1 before migrating), which stored a little less than a dozen local repositories and provided a proxy and cache for twenty external repositories (for almost 400GB of data).
The majority of that space was used by the repository of internal snapshots (200GB) and the repository of internal releases (150GB). To understand these sizes you must know that some projects may produce (for good or bad reasons) some EARs up to 100MB in size. By adding the sizes of JARs and WARs that compose these EARs, each deployment quickly grows to take up a lot of space.

Why change?

For several months we were having stability issues with our integration environment. From one build to another we would see execution times fluctuate widely. We also had intermittent errors that were not related to projects, but to the infrastructure :

500 or 502 errors on uploads in Archiva without any apparent reason (I tried to track down the issues without success),
Many periods of unavailability of Archiva or Bamboo after exceeding the maximum number of open file descriptors allowed for the user. We must concede that these tools handle a lot of files (downloads, uploads, and other manipulations on a large number of artifacts). Archiva easily exceeds the default limit of 1024 descriptors which forced us to increase it. But even at 2048 Archiva would still occasionally exceed the limit.
Inability to download snapshots if the local repository used by Bamboo was emptied just prior to that. This resulted in regular failures of our Maven sites or Sonar builds.

We recently submitted a bug against Archiva (MRM-1136), for which I spent several hours diagnosing the issue (problems with management of meta-data issued by Maven 2.1.0). To resolve the issue would require us to quickly upgrade to Archiva 1.1.4 or 1.2.

All of these problems, even though they were only occasional, strongly discredited our continuous integration service. How could we criticize a project for not using our CI if it kept sending them false negatives? They already have enough work with addressing real errors in their builds. The continuous integration environment must be as reliable as a Swiss watch.

It was time for us to act.

We could update Archiva, which would entail significant validation costs without much improvement. Apart from the incompatibility with Maven 2.1.0, nothing suggested that the new version fixed any of our problems and there were few improvements/new features at that time, due to lack of time by the maintainers.

The other choice was to get another tool with the potential to meet the new requirements.

The feedback from the community about Nexus was very encouraging. Moreover, the latter pro version opens up new possibilities for the future with its innovative features:

Staging repositories to put artifacts being validated in a temporary area prior to delivery.
Opportunity to proxy and aggregate eclipse update sites. Currently we are doing it by hand, which is expensive, complicated (I hate P2), and boring.
and more…

As the situation seemed to be calling for it, we decided to try our luck with Nexus.

Migration

Let’s get started.

Existing environment

A little overview of our existing environment. Before the migration, our environment was like this:

The environment before the migration

We were hosting our internal repositories in what Archiva calls managed repositories. There is one for releases, one for snapshots and another one for third-party libraries (often those delivered by closed-source vendors).
To cache external repositories (configured as « remote repositories ») we are using two more repositories (one for external releases and one for external snapshots).

Our Archiva shows two groups: One to access released artifacts, and another one for snapshots. We never set up a unique group with access to both of them because in our tests we noticed that Archiva often had issues merging descriptors coming from several repositories (maven-metadata.xml), and it can have dramatic consequences if you mix up releases and snapshots.

Groups allow to greatly simplify Maven configuration, avoiding the need to declare too many repositories. Moreover, they enhance your Maven experience, speeding up your builds. Each missing dependency request is sent only once to each group, while the process in the background polls each repository in the group and maintains a cache about missing dependencies to further speed up the build. Sending missing dependency requests to several repositories is an inexcusable waste of time.

Repository users (developers and the continuous integration server) access them using these settings :


  
    
      default
      
        
          central
          http://serveur.entreprise.fr/archiva/repository/releases/ 
          true
          false
        
        
          snapshots
          http://serveur.entreprise.fr/archiva/repository/snapshots/ 
          false
          true
        
      
     
        
          central
          http://serveur.entreprise.fr/archiva/repository/releases/ 
          true
          false
        
        
          snapshots
          http://serveur.entreprise.fr/archiva/repository/snapshots/ 
          false
          true
        
      
    
  
  
    default

By redefining the central server address (normally located here: http://repo1.maven.org/maven2/) we configured Maven to look only for released artifacts in our group in Archiva. This gives us access to both internal and external releases. In the same way, the repository snapshots allow us to obtain development versions of all artifacts.

Constraints

Migrating a server isn’t easy when you have 200 developers using it every day.

First, we had to be sure to only stop the service for a very short time (or we would have to do it outside of working hours… ouch!!!). Stopping the continuous integration server temporarily isn’t such a big problem. Asking all teams to use maven in offline mode, and not to use our repositories is more difficult. Usually, we don’t have to wait long before someone needs to download a new artifact or a project has to do a release.

Secondly, it was mandatory for us to keep the compatibility with preexisting Maven settings. Due to the large number of projects and developers it would be impossible to change all repositories settings in Maven configuration. It would impact all projects and all developers if we changed the upload URLs (distributionManagement) and download settings (repositories).

The process

To reduce cost, we decided to not perform our tests in a test environment. This would require us to duplicate the entire integration environment we have in production.
After some basic tests performed on the tool, the real baptism by fire was the scalability of the server (with an increasing volume of data and number of users).
During migration system resources allowed us to easily handle both servers in parallel. We chose the strategy to run Archiva and Nexus in parallel and to switch services to the new server one after another, while keeping the fallback option to revert if necessary.

We had enough space to rebuild caches of external repositories (this required only a few gigabytes), however we could not duplicate our internal repositories, which are too large, and we could have consistency issues. We also did not want to give both products access to internal repositories, because we feared they might access them simultaneously and corrupt our data. Therefore we began our migration leaving our internal repositories on Archiva planning to move them to Nexus at the end of migration.

For URL compatibility we used rewriting rules on the Apache server. It would switch between old and new URLs in a transparent manner.

Installing Nexus

We performed a classic installation of Nexus 1.3.2 (the opensource and standalone bundle) adjusting a few parameters such as the HTTP port, the paths of data and log directories to conform to the organization of our server. All this was quickly done because unlike Archiva we did not have to create a database (which had to be in mysql to follow our standards). Our server was up and ready to be configured.

Configuration of groups and external repositories

We started the Nexus configuration by creating proxy repositories. We also added, for purposes of migration, proxies for our internal repositories hosted on Archiva.

The GUI is ergonomic which makes the registration of 20 external repositories very bearable. Thank you ExtJS!

Unlike Archiva which proposes to store the artifacts of external repositories in the same local repository, Nexus stores the contents of each in a dedicated repository (proxy).

Regarding settings of external repositories, it should be noted that we lose the opportunity provided by Archiva to have white and black lists of artifacts coming from each external repository. Nexus uses the concept of « routes » for this type of filtering. Unfortunately we can apply those routes only at a group level and not on a repository.
Since some lists that we have in Archiva are only for performance issues (e.g. do not query a repository in which we know that a certain artifact is not located), we decided to not duplicate this setup in Nexus waiting to see if there were real problems.

In our setting we faced a first disappointment. As we have to proxy some repositories hosted internally (the one delivered by the Sonar server and all of those always on Archiva during the migration) we were forced to declare the company web proxy on each proxy repository. It is impossible to define the web proxy in the global configuration of Nexus and to disable it on a given proxy repository (NEXUS-2317).

While our external repositories configuration was almost complete, we had our first big setback. We discovered that it was impossible to proxy repositories which are in the legacy layout of maven 1 (at Atlassian and dev.java.net for example).
To achieve this we need to create virtual repositories which are used by Nexus to convert a repository from one format to another. Tough luck, because two bugs (NEXUS-1909, NEXUS-1910) prevented us from doing it.
Fortunately for us, the Nexus team has been very responsive and was able to incorporate the corrections to these bugs in version 1.3.3 which was published the day after our discovery. Otherwise we have to admit that we probably would not have continued our tests on Nexus.
We have updated our server which allowed us to see that the process was very simple since the application, its configuration, and the data were all well separated.

We finalized the configuration of Nexus by creating groups. That is the same concept as in Archiva (which copied it).
The configuration of groups is however relatively poorly designed in terms of ergonomics. We had to select each repository we wanted to add to the group and then put it in the correct order in the list. The order is very important, because Nexus will use it to search for artifacts. We must therefore place internal repositories prior to external ones. The problem is that this list displays only the name of each repository (and the name is often truncated because of its length). So you should be careful in naming your repositories to be able to easily sort them when you have several dozen in a group.

We followed Nexus recommendations by creating a single group that exposes all releases and all snapshots. (This will help us avoid having to battle the screen for configuring a group twice ).

From now we were supposed to be able to download all artifacts needed to build our projects with Nexus.

After several successful tests on our desktop we tested the whole system with our continuous integration server.
We deleted its local repository and updated its configuration:


  
    
      
      nexus
      *
      http://serveur.entreprise.fr/nexus/content/groups/public/ 
    
  
  
    
      default
      
      
      
        
          central
          http://central 
          true
          true
        
      
     
        
          central
          http://central 
          true
          true
        
      
    
  
  
    
    default

Please note: I am not at all a fan of using the mirror * which requires us to put releases and snapshots in the same group. However, this is the only solution, as there is no way to tell Maven to find releases on one mirror location and snapshots on another one. I find this dangerous because e.g. when you call a plugin without defining its version (a plugin in command line such as eclipse:eclipse or archetype:generate) you may retrieve a snapshot version of it. Thus you have to take care to follow the recommendation of Maven to define all the versions of plugins that are used in your project descriptor (directly or by inheritance) to avoid surprises. In our context we won’t have this issue since the recommendation is followed by all projects using a parent POM that is setting all versions for them.

The environment with Nexus and Archiva running in parallel was now ready to go :

The environment while migrating

Nothing changed for developers who still use Archiva while the continuous integration server retrieves all artifacts from Nexus.

Tuning

After testing it a few days we could see that Nexus sometimes had difficulty quickly delivering artifacts. The time has come to look at a few more advanced settings.

Routes allow to restrict the list of repositories that Nexus has to verify when we request an artifact to a group. This can be done via permissions or prohibitions.

The first route we create is the one which tells to Nexus to search for our artifacts (.*/com.mycompany/.*) only in proxy repositories giving access to our internal artifacts on Archiva. When the switch to Nexus will be completely finalized, this route will point only to our internal repositories hosted by Nexus.

We also add rules for .*/org/apache/.* and .*/org/codehaus/.* which are heavily used by Maven, so that artifacts are retrieved only from the central repository and snapshots repositories of each community.

This gave a pretty good boost to our Nexus implementation.

After several days of use by the continuous integration server, Nexus was running fine. Therefore we got ready for the second part of our migration: hosting of our internal repositories on Nexus.

Setting internal repositories and security

Before we could move internal repositories from Archiva to Nexus we had to create hosted repositories. We created directories for our repositories in a different location from Archiva, as to not let both products access the same data. We reused repository identifiers used in Archiva to easily create rewriting rules on Apache HTTP server.

We spent some time learning the security mechanism in Nexus. Settings are so fine that even the most basic use cases require convoluted settings.

We began by creating privileges (read, write, update) on each hosted repository. We created roles that grouped some privileges on hosted repositories together. In our case, one role to deploy released artifacts on repositories (for projects teams) and another role to deploy snapshots on repositories (for continuous integration server).

We finished by creating users with roles defined above without forgetting the role to download from any repository.

Internal repositories were ready, all was left to do was to move data to Nexus and to stop Archiva.

The final steps

To keep the compatibility between Archiva and Nexus we had to do two things.
For each internal repository on which we’ll have to upload artifacts we explicitly wrote a rule to transform the URL from Archiva to Nexus.
Apache configuration example:

RewriteRule ^/archiva/repository/internal-releases/(.*) http://localhost/nexus/content/repositories/internal-releases/$1 [P]
RewriteRule ^/archiva/repository/internal-snapshots/(.*) http://localhost/nexus/content/repositories/internal-snapshots/$1 [P]
RewriteRule ^/archiva/repository/third-parties/(.*) http://localhost/nexus/content/repositories/third-parties/$1 [P]

For all other types of read access we just created a rule which transfered them to our unique group in Nexus.
Apache configuration example:

RewriteRule ^/archiva/repository/[a-z\-]+/(.*) http://localhost/nexus/content/groups/public/$1 [P]

Now we were ready to migrate:

Stop Nexus.
Stop Archiva.
Install rewriting rules on Apache.
Move content of internal repositories from Archiva to Nexus.
Restart Nexus.

On D-day we made the switch in less than 10 minutes. Nexus took a few hours to index the hundreds of GB of data, but without taking much of a performance hit.

The final environment

Despite some pitfalls we encountered, the migration wasn’t technically really complex. We did it in 2 weeks and we spent less than half that time actually working on it.

Now we are studying how to configure scheduled services. Sonatype made a major effort on product documentation. It allows us to quickly discover all its features. However, we are disappointed when we want to go further than the reference guide. Some best practices about the usage of the tool in a corporate environment are still missing:

What scheduled tasks should be used?
Under what circumstances?
When?
Why should we repair metadata?
Why should we delete caches?
How are we supposed to use the trash?

Results

Two weeks after the migration we drew a first conclusion of our Nexus experience.

Let’s begin by changes on issues we previously had with Archiva and which led us to attempt the Nexus adventure.

The number of file descriptors simultaneously opened

It’s a little bit early to declare victory, however after running for two weeks we can see that our problem on the number of file descriptors opened simultaneously disappeared. Whereas Archiva easily exceeded the 1024 descriptors opened, Nexus uses only 400 which enormously reduces the load on the server.

Number of file descriptors simultaneously opened by Archiva

Number of file descriptors simultaneously opened by Nexus

Memory consumption

Even if we had enough RAM, Archiva is a big consumer of memory. Archiva took an average of 1.3 GB to run. Nexus requires many less and works with 400MB (Even my Eclipse requires more ). It saves almost 1GB that we can now allocate to our builds.

Memory consumption by Archiva

Memory consumption by Nexus

Not found snapshots

Sadly this problems always persists. Because migration to Nexus hasn’t fixed it, we investigated a little bit more and discovered two causes for it :

The first one is a bug in Maven (MNG-4142) : It’s a subtle problem halfway between the use of artifacts with classifiers and a corruption of metadata in the local repository.
The second one is a set of bugs in Nexus (NEXUS-1333, NEXUS-2036): The scheduled service used to repair metadata deletes them if it cannot read it. The problem is that it doesn’t succeed to read them if you are using some deprecated properties like {parent.*} (replaced by ${project.parent.*}) or ${pom.*} (replaced by ${project.*}). Note that NEXUS-2036 is marked as fixed on version 1.3.4.

Nothing is perfect

A bug we didn’t have before appeared with the usage of Nexus. Because of our usage of rewriting rules in apache, Maven now complains that cookies are rejected when we upload artifacts on an internal repository (NEXUS-1967). This is a minor issue which doesn’t alter our system, but is annoying because it pollutes our Maven logs on the integration server.

But we had a good surprise

Resource savings on the server (IO, RAM) and the quality of Nexus on the speed to upload artifacts (whatever their size) lead to an important improvement of quality of service and stability of the continuous integration server. As you can see below on some graphs taken from different builds in Bamboo there’s a big difference between before and after Nexus. Build times decreased and are consistent like never before.

Conclusion

Did we find the silver bullet ? Of course, no. I have already listed some constraints and problems we had and there are probably many others to discover (the team already has a good backlog). Any product can be improved. Despite all that, how could I say something other than… migrate! It’s unfortunate for me to have to admit this as a member of the Archiva team, but my own research proves it. Nexus is a product of great quality, which delivers the service you need for your development projects very well. Furthermore, developed by full-time employees (thank you Sonatype), it enjoys an easily accessible and responsive support (I recommend the channel #nexus on #irc.codehaus.org). Archiva itself is governed by the laws of open source, suffers from the lack of time of its maintainers (even if they are doing as much as they can) which doesn’t help it to stay in the competition.

So, enjoy and benefit from service and quality by adopting Nexus!

Rating: 10.0/10 (1 vote cast)