Comme annoncé dans le précédent article, jeudi soir avait lieu une soirée JUG sur la gestion de dépendances. Le titre : Maven / Ivy VS OSGi.
Petite introduction de la part de l’auteur, retrouvable sur le site du Toulouse JUG : « La gestion des dépendances, sac de noeuds presque par définition, on va essayer de démêler tout ça.
Après avoir fait un état des lieux avec Maven car il est l’incontournable du moment, nous irons voir comment Ivy peut décrire assez finement et gérer avec souplesse des dépendances. Nous verrons ensuite comment le modèle de dépendances d’OSGi est original et apporte encore de nouveaux concepts. Deux mondes s’affrontent alors, celui de Maven et Ivy face à celui d’OSGi; on tentera enfin d’esquisser un meilleur des deux mondes. »
Cette introduction a pour mérite d’avouer que la gestion des dépendances en informatique, c’est un gros problème et un gros travail pour tout projet qui se respecte… Je connais très mal ces problématiques à vrai dire… Je vais donc me contenter de faire un petit résumé des concepts entendus lors de cette présentation de Nicolas Lalevée :
Bon, mais commençons par le commencement… Qu’est ce que la gestion de dépendances ? C’est juste le fait de constater qu’en général nous ne partons jamais de rien, mais nous utilisons toujours une brique déjà finie, et c’est tout le thème de la soirée. Pour la peine, la gestion de dépendances, nous la rencontrons un peu partout (la gestion de paquets Debian, les simples imports dans une classe Java, les include en général en programmation, slide 30/53). Bref dans nos projets Java, nous avons toujours toute une liste de librairies qu’il est plus ou moins compliqué de gérer : Maven et Ivy sont là pour nous aider.
Tout d’abord Maven, outil d’intégration continue par excellence… Maven a un beau nombre de supporteurs, d’ailleurs ça s’est bien ressenti dans l’assemblée 🙂 Complètement intégré au monde Java, Maven va permettre l’intégration des dépendances jar de son projet en fonction de la version du Jar (version d’implémentation). C’est important pour la suite.
Ivy est un peu différent. Déjà, parce qu’Ivy ne sert qu’à gérer des dépendances, alors que les dépendances dans Maven ne sont qu’un maillon du processus d’intégration continue. De plus, Ivy n’a rien à voir avec le monde Java. Ivy, c’est là pour gérer des fichiers, qui ont un nom et une version donnée pour une implémentation, grosso modo, et cette séparation du monde Java permet une complète souplesse très très appréciée par Nicolas Lalevée, notre orateur d’un soir.
Si je résume, Maven est efficace et éprouvé pour la gestion de dépendances dans le monde Java, Ivy apporte une souplesse totale pour de multiples utilisations, mais tout cela reste dans la même philosophie : récupérer une version d’implémentation donnée d’une dépendance, pour générer une instance unique (« mono-artefact ») de son projet.
Nicolas Lalevée a voulu confronter cette philosophie à celle d’OSGi. Rien à voir me direz-vous, et bien si… OSGi gère ses dépendances dans ces fichiers MANIFEST. Même si OSGi est moins souple par certains aspects (par exemple, pas possible d’avoir un profil de Manifest pour générer un projet dédié à sa phase de test…), il y a une chose très intéressante : OSGi va s’intéresser à la version de l’API, et pas de son implémentation ! C’est vrai que c’est primordial finalement… Si l’API ne change pas dans la dépendance, qu’importe la version d’implémentation, on sait que ça « compilera ».
Bref, Je vous invite à regarder aux alentours du slide 49 pour voir le système de gestion de dépendances idéal pour Nicolas…
En tout cas c’est une problématique intéressante, même si je suis loin de maîtriser parfaitement toutes ces notions… D’ailleurs je suis ouvert à toute lecture ou toute remarque pour approfondir le sujet!
LB.