new Blog( perso );

Lorsqu'on cherche à convertir un projet "old-school" sous Maven, l'une des premières tâches consiste à identifier la liste de dépendances du projet. On peut se baser sur le nom des JAR, éventuellement se rassurer en inspectant le fichier MANIFEST (lorsqu'il est renseigné), mais en général c'est :

• long
• barbant
• peu fiable : j'ai déjà vu des JAR "patchés" ou "complétés" avec des classes annexes

Une solution plus propre consiste à se baser sur les empruntes MD5 et SHA1 que le repository Maven conservent pour chaque artefact. Une simple recherche Google sur cette clé retourne l'identification précise d'une bibliothèque (avec parfois des surprises !).

Il y a pourtant encore plus simple...

Le repository manager Nexus propose un moteur de recherche qui prend en entrée l'emprunte SHA1. Basé sur son index interne, il va nous retrouver la bibliothèque, et en plus nous indiquer les versions plus récentes (si on veut en profiter pour un petit lifting). L'avantage de Nexus, c'est qu'il propose une API REST qui permet d'automatiser tout ça. Allons-y donc gaillardement !

J'écrit donc mon tout premier script Ruby ! - et oui, tout fout le camp ma bonne dame - ce langage est génial pour écrire des scripts de ce type, avec des bibliothèques bien puissantes ;)

require 'find'
require 'digest/sha1'
require 'net/http'
require 'rexml/document'
include REXML

for file in Dir.glob("*.jar") do 
    sha = Digest::SHA1.file( file ).hexdigest
    url = "http://myNexus/service/local/lucene/search?sha1=" + sha 
    resp = Net::HTTP.get_response( URI.parse( url ) )
    puts File.basename( file ) + " (" + sha + ") = \n";
    doc = REXML::Document.new( resp.body )
    XPath.each( doc, "//artifact" ) do |r|
          puts "<dependency>"
          puts "   <groupId>#{r.elements["groupId"].text}</groupId>"
          puts "   <artifactId>#{r.elements["artifactId"].text}</artifactId>"
          puts "   <version>#{r.elements["version"].text}</version>"
          puts "</dependency>"
    end  
 
end

Rien de bien méchant, comme vous pouvez le constater, et ce script permet d'analyser rapidement une liste de jar en proposant les éléments à intégrer dans le POM. Il restera "juste" à identifier les bibliothèques qui seront passées entre les mailles du filet.

Maintenant que Maven Indexer est un projet Apache (depuis la version 3.1.0), ce serait bien d'intégrer cette fonctionnalité au plugin dependency [MDEP-269] ... ou ailleurs.

2011 pourrait bien être l'année du fork.


Non, je ne parle pas du nouvel an chinois, mais de la scission d'une communauté open-source (fork).

Le premier va se dérouler du côté du serveur d'intégration continue Hudson.
Après avoir géle puis migré le projet (sans prévenir) de l'infrastructure java.net vers kenai, Oracle réclame aujourd'hui le pilotage du projet, ou en tout cas l'application de règles strictes de pilotage et de cession des droits sur les contributions. La communauté ne suit pas, prise depuis le début à rebrousse-poil, et a déjà migré sur gitHub et google-groups.

Les dernières tentatives d'accord pour trouver un arrangement acceptable, légitimant une communauté indépendante sans couper les ponts avec Oracle, ne progressent pas. On s'oriente donc à grand pas vers un changement de nom pour Hudson (la seule chose qu'Oracle possède encore c'est ... ce nom "hudson ®") qui deviendra Jenkins.

La communauté Hudson - légitime en terme de lignes de code - se retrouve donc face à Oracle qui ne lâche pas grand chose, fort de sa légitimité sur le nom "hudson" et l'historique du projet.

Le second pourrait se dérouler du côté de Maven. 
Critiqué pour son pilotage unilatéral du projet au travers de sa société Sonatype, Jason Van Zyl a claqué la porte du Project Management Committee Maven. Fondateur du projet, il ne participe donc plus à ces discussions (qui a dit "disputes" ?) et continue à bosser avec ses collègues sur l'outil qui fait vivre sa boite, mais sur gitHub plutôt que dans le SVN Apache. Le code reste opensource, accessible à tous, mais ne suit plus les règles de bonne conduite communautaire édictées par la fondation. Sans a priori sur les personnalités en présence, ce n'est pas la première fois qu'un leader se plaint du modèle Apache et finit par aller voir ailleurs [1].

Les raisons de la crise : une partie non négligeable de Maven (Aether) est désormais hébergée chez Sonatype, et bien que toujours opensource, est vécue par certains contributeurs Maven comme une perte de contrôle (nécessité de signer une CLA pour contribuer). Comme pour ajouter à la sauce, Modello et Plexus, deux projets "socle" de Maven, ont été déplacés sur le gitHub Sonatype puis fermés sur codehaus.

Jusqu'ici les échanges liés à ces frictions sont restés discrets, la fondation Apache ayant pour règle de gérer ce genre de conflit en privé. Avec la contribution de Sonatype dans la fondation Eclipse via le projet m2eclipse, un changement de license [2] sur un composant a ébruité publiquement la situation.

Il ne s'agit pas (encore) d'un fork, mais rien n'interdit à Sonatype de publier ses propres releases de Maven (mais pas Apache Maven) dans le cade de son offre Sonatype Professional, le nom n'étant pas déposé par la fondation. Le PMC doit donc trouver un compromis, définir des règles sur l'utilisation de ces composants "externes" qui constituent pourtant une part importante de Maven 3 (core), et voir comment intégrer les développements de Sonatype tout en conservant un pilotage à la Apache du projet et en continuant à assurer la maintenance des nombreux plugins qui - eux - restent un terrain de jeu équitable pour tous les contributeurs (les moins doués se contentant d'écrire des bouquins sur le sujet).

La communauté Apache Maven - légitime en terme de contribution historique et de support - se retrouve donc face à Sonatype, fort de sa légitimité sur la quasi-totalité du travail de développement de Maven 3.

Inutile de vous dire à quel point ces querelles de légitimité, de licence, de règles de pilotage sont à la fois passionnantes et barbantes pour les contributeurs qui passent un temps fou à éplucher les mailing-list abreuvées de messages enflammés. 2011 risque de ne pas être une année reposante.




[1] le développement de log4j 1.3 est quasi abandonné, englué dans des discussions sur le maintien de la compatibilité. Ceki Güclü a préféré reprendre à 0 avec l'excellent slf4j.
[2] https://github.com/sonatype/sisu, notez les deux fichiers LICENCE.txt. Sous licence EPL, le code associé n'a plus aucune chance de revenir à la fondation