new Blog( perso );

J'ai alors contribué à Archiva pour supporter la conversion à la volée des requêtes Maven1 sur une repository Maven2. Ca m'a valu mon titre de committer puis de PMC sur le projet. Archiva a ainsi tourné quelques temps en version SNAPSHOT pour remplacer le proxy vieillissant. Si le service était là, ça restait du developpement "direct to production" pour corriger les divers problèmes rencontrés.

Force est de constater qu'après cette date j'ai manqué de temps pour contribuer à Archiva, et que le repository associé, géré par un Archiva 1.0 en manque de suivi, est lui aussi parti en vrille. Au dernière nouvelles, il n'arrive plus à télécharger de nouveaux JARs (sans doute à cause des métadonnées), et la tentative de mise à jour vers une version récente d'Archiva a été un échec. Il faudrait reconstruire toute la conf et le repo, pas le temps ...

Je me tourne donc vers Nexus, que j'ai du installer pour un gros projet afin de publier des SNAPSHOTs, évitant à chaque membre de l'équipe de devoir ouvrir 20 modules sous Eclipse. Il faut bien l'admettre, Nexus marche très bien et sa configuration de base est à la portée du premier venu.

Le temps est donc venu de trahir ceux qui m'ont offert mon eMail en "@apache.org" et de renier Archiva pour passer à Nexus -- le côté obscur de la force, tout ça.

Step 1 : demander la création d'une VM - avec un gros disque - et y installer un Ubuntu (y'a que ça de vrai)

Step 2 : suivre la doc de Nexus qui est tellement bien faite que ça fait mal pour les autres

Step 3 : configurer les proxies qui vont bien pour récolter sur le Net toutes les bibliothèques qui vont bien

Step 4 [c'est là que ça devient intéressant] : jouer avec les rôles pour autoriser finement l'accès au repository private, là où chaque projet va pouvoir déployer ses propres artefacts. L'idée est de fournir un réceptacle commun, afin de limiter la conf, mais de restreindre l'accès en fonction des projets considérés pour ne pas risquer de se marcher sur les pieds. Je ne cherche pas à réinventer la poudre, je me base simplement sur les articles qu'on trouve sur le blog de sonatype [1] et [2].

Résultat des courses : 
En deux heures à peine, j'ai un système qui sert de cache pour les accès au repos central, jboss, apache.snapshots et compagnie. Pour chaque projet qui en fait la demande, je crée juste un nouveau rôle correspondant au groupId sélectionné et un user avec ce rôle. Le projet peut alors déployer à sa guise ses propres binaires.

Dans les quelques cas où un binaire "commun" est proposé, si on me fournit des métadonnées propres, une identification de version bien faite et tout ça, j'upload dans le repo thirdParty pour tenir compagnie au driver jdbc Oracle et aux classes du client MQSeries.

Pour les projets qui n'arrivent pas, ou n'ont pas l'habitude d'identifier la version exacte ou la provenance d'un binaire (généralement un legacy ou un progiciel), le déploiement est fait dans le groupId du projet, pour éviter de polluer le reste du repository avec des artifacts peu fiables.

Conclusion :
Les mécanismes avancés de Nexus en font une solution de choix. Si je n'ai pas fait un monitoring aussi poussé qu'Arnaud sur le sujet, il est clair qu'il est plus stable et moins consommateur qu'Archiva. Par ailleurs, installation et configuration sont un jeu d'enfant, qui plus est avec une doc d'une grande qualité. Et pour ceux à qui ça ne suffirait toujours pas, il y a encore la version "Pro" avec des fonctionnalités encore plus riches, à voir si vous en avez l'usage.

Nexus me retire une aiguille du pied, nous avons maintenant un repo "agence" fiable et facile à administrer. Une ressource facile à mettre en commun et qui facilite la vie.