new Blog( perso );

"Maven télécharge tout l'Internet", ça doit être la phrase la plus couramment utilisée par les développeur Java (juste après "Eclipse est encore planté"). En bossant chez CloudBees j'ai le plaisir (?) de découvrir des outils de builds en tout genre que nos utilisateurs veulent mettre en oeuvre sur DEV@Cloud, ou même notre propre équipé d'ingé qui - semble t-il - a pour règle d'utiliser exclusivement des langages de programmation que Sacha (notre CEO) ne pourra pas comprendre, histoire d'avoir la paix.



Avec Maven 2 on avait donc le plaisir de télécharger 4 ou 5 versions de commons-lang, Maven partant du principe que si le plugin P demande la version V, il faut le faire tourner avec la version V dans son classpath, et pas avec la version N demandée par le plugin Q. PV != QN, pas compliqué et assez logique.

Maven 3 ajoute une gestion avancée des méta-données et trace de quel repository vient telle dépendance pour s'assurer que votre projet ne va pas utiliser la version Q alors qu'elle n'existe pas dans les repositories que vous déclarez. Logique, mais déjà plus compliqué, et la connection au Net chauffe un peu au passage.

Regardons un peu ce qui se fait ailleurs :

En PHP, le gestionnaire s'appelle PEAR et est un petit rigolo.
pour installer le paquet "timer", on fait pear install phpunit/PHP_Timer. Simple et de bon gout. Si le paquet a des dépendances, on ajouter --alldeps pour qu'il les installe au passage. Jusqu'ici, ça va - c'est ce qu'on dit quand on saute du 50ème étage. Arrive le moment où on a un conflit de version, et le paquet "phpqatools" par exemple qui nécessite timer en version >= 1.0.4. En local, pour diverser raisons j'ai déjà ce paquet en version 1.0.2.




Pas cool. Il n'existe aucune option pour forcer un upgrade des dépendances.

La doc officielle indique même que la commande install ne va pas faire d'upgrade si le paquet est déjà présent, ce qui n'est pas mon cas :




Vous me direz, s'il faut que la doc soit à jour, ... Mettons. Bon alors moi, naïvement, je me dit je vais lancer un pear upgrade pour être sur d'avoir les dernières version installées, comme ça je suis tranquille. Et bien, la bonne blague c'est que cette commande réinstalle les librairies, même celle qui sont à jour. Super pratique pour écrire des recettes de gestion de l'infra qui vont être rejouées en boucle.

Allez, y'a plus rigolo :

En Erlang, le gestionnaire de paquet s'appelle Rebar. Alors là, on se fait pas chier : pour obtenir une dépendance, on clone son repo git. Si la dépendance a elle aussi un fichier rebar, on fait la même chose en mode récursif. Hop, voilà, c'est tellement plus simple de tout recompiler from scratch.


La différence avec Java, c'est que le compilo Erlang est très rapide, aussi ce n'est pas pénalisant, mais ce serait fun un outil de build java qui récupère les sources apache commons, spring, bidule et chose et recompile le tout. Ca tente quelqu'un ?