Réflexion autour de Ant, Ivy, Maven et les utilisateurs de tels produits
Ivy a eu sa petite heure de gloire ce printemps car il apportait une sympathique gestion de dépendance transitive à des projets compilés avec Ant, ce qui a intéressé beaucoup de monde.
Les blogs de l'époque en ont profité pour exprimer la récurrente plainte contre les défauts de Maven : trop de temps à être livré, complexité pour rentrer dans son cadre.
Il me semble mieux comprendre ce dernier grief, après quelques lectures;
Distinguons 2 approches d'organisation de projet.
La première souhaite de la flexilibilité et de la rapidité de mise en oeuvre : j'ai 1 arbre de sources comprenant tous mes modules, et je veux rapidement produire un script générant toute une série de target.
La seconde accepte de se poser un peu plus, d'adapter l'organisation de ses sources pour coller à un modèle élaboré défendu par un outil qui, en échange, fournit une énorme puissance d'automatisation.
Dans les 2 cas, on apprécierait de pouvoir gérer les dépendances de façon transitive: marre de remettre à jour les dépendances de tous mes modules du haut quand ça change en bas.
Typiquement les premier font du Ant, et ont vu la venue d'Ivy comme une libération de l'obligatoire migration vers Maven 2 ! Typiquement les seconds mettent en place Maven, sont souvent enthousiastes, prennent le temps de se former à Maven 2, utilisent même en avance les versions béta et même les snapshots CVS.
(aparté: du fait, ils sont même obligés, étant donné la politique de release de l'équipe Maven : (trop) soucieuse de délivrer l'outil parfait ? en tout cas de ne livrer que lorsque tout est stabilisé pour éviter aux utilisateurs de trop nombreuses migrations; pas de bol, ces derniers ont besoin d'avancer, utilisent les snapshots et beta, et donc migrent...)
J'ai alors observé que la première démarche correspondait au profil projet de framework opensource sur internet, avec quelques développeurs, ne travaillant qu'à temps très partiel sur leur biniou, bref n'ayant pas de temps à rentrer dans un cadre restrictif, mais demandant plutôt un outil tout terrain. Et que je comprends vraiment cette approche, elle est vraiment rationnelle et intéressante.
Là où ça devient drôle, c'est qu'on se dit que ce profil peut s'appliquer aussi... à de nombreux projets framework et même applicatifs d'entreprise !
Ant a vraiment de longs jours devant lui; et Maven n'a pas eu tort de rendre disponible sous forme de taches Ant son système de gestion de dépendance transitive (malin ça). Ivy persistera-t-il dans le monde Ant ? L'avenir le dira, mais je ne dirai pas comme mon collègue bien aimé que Ivy est mort avec la création de Maven 2. Maven 2 n'est pas encore buildé en beta, encore moins sorti, il peut arriver encore des choses!
Les blogs de l'époque en ont profité pour exprimer la récurrente plainte contre les défauts de Maven : trop de temps à être livré, complexité pour rentrer dans son cadre.
Il me semble mieux comprendre ce dernier grief, après quelques lectures;
Distinguons 2 approches d'organisation de projet.
La première souhaite de la flexilibilité et de la rapidité de mise en oeuvre : j'ai 1 arbre de sources comprenant tous mes modules, et je veux rapidement produire un script générant toute une série de target.
La seconde accepte de se poser un peu plus, d'adapter l'organisation de ses sources pour coller à un modèle élaboré défendu par un outil qui, en échange, fournit une énorme puissance d'automatisation.
Dans les 2 cas, on apprécierait de pouvoir gérer les dépendances de façon transitive: marre de remettre à jour les dépendances de tous mes modules du haut quand ça change en bas.
Typiquement les premier font du Ant, et ont vu la venue d'Ivy comme une libération de l'obligatoire migration vers Maven 2 ! Typiquement les seconds mettent en place Maven, sont souvent enthousiastes, prennent le temps de se former à Maven 2, utilisent même en avance les versions béta et même les snapshots CVS.
(aparté: du fait, ils sont même obligés, étant donné la politique de release de l'équipe Maven : (trop) soucieuse de délivrer l'outil parfait ? en tout cas de ne livrer que lorsque tout est stabilisé pour éviter aux utilisateurs de trop nombreuses migrations; pas de bol, ces derniers ont besoin d'avancer, utilisent les snapshots et beta, et donc migrent...)
J'ai alors observé que la première démarche correspondait au profil projet de framework opensource sur internet, avec quelques développeurs, ne travaillant qu'à temps très partiel sur leur biniou, bref n'ayant pas de temps à rentrer dans un cadre restrictif, mais demandant plutôt un outil tout terrain. Et que je comprends vraiment cette approche, elle est vraiment rationnelle et intéressante.
Là où ça devient drôle, c'est qu'on se dit que ce profil peut s'appliquer aussi... à de nombreux projets framework et même applicatifs d'entreprise !
Ant a vraiment de longs jours devant lui; et Maven n'a pas eu tort de rendre disponible sous forme de taches Ant son système de gestion de dépendance transitive (malin ça). Ivy persistera-t-il dans le monde Ant ? L'avenir le dira, mais je ne dirai pas comme mon collègue bien aimé que Ivy est mort avec la création de Maven 2. Maven 2 n'est pas encore buildé en beta, encore moins sorti, il peut arriver encore des choses!
Commentaires