Ivy, Maven, OSGI : gestion des dépendances au JUG Toulouse

  • Sharebar

Nouvelle session au Toulouse JUG sur la gestion de dépendances.
Bon, bouchon : j’ai raté le Quizz et je suis arrivé à la fin, donc je n’ai pas pu gagner la licence IntelliJ comme je l’avais prévu en répondant à toutes les questions ;-) .

3 outils sur le tapis : Maven (la brute ?), Ivy (le bon?) et Osgi (le truand ?).
Nicolas Lalevée (Comitteur Apache Ivy) commence par expliquer le niveau 0 de la gestion dépendance : un répertoire lib, on télécharge les “jar” :

  • ça compile ?
    • oui : on arrête
    • non : on rajoute des jar
  • ça tourne ?
    • oui : on arrête
    • non : on rajoute des jar

OK, OK : j’avoue, j’ai péché, dans ma jeunesse moi aussi j’ai créé des répertoires lib.

Nicolas s’occupe ensuite du cas de Maven. Maven fait tout : build (que vais-je faire ?), gestion des dépendances (de quoi ai-je besoin ?) , container pour créer de nouveaux plugins. Rappel : la session Maven par Arnaud Heritier au JUG Toulouse

Son modèle de dépendances en résumé :

  • Gestion du nommage organisation / nom / version
  • Mono artefact : Maven est plutot orienté pour générer un seul artefact (il existe tout de meme des astuces pour génerer +ieurs “outputs” -> Cargo peut générer 2 jar (interfaces remote + appel locaux).
  • La gestion des dépendances d’un module peut être à usage :
    • interne : compiler, tester, exécuter le module courant
    • externe : on donne l’option de ne pas tirer les modules du “monde entier”
    • pour le runtime : l’intégration du module courant dans un container (ex : JEE) fait qu’on a besoin de dépendances pour le module (compilation etc ..) mais ces dépendances sont inutiles lorsque le module est déployé (ex : servlet-api).

Bon, c’est factuel, mais on sent bien qu’il en garde sous la pédale pour Ivy ….que voila.

Ivy se concentre sur la gestion de dépendances de fichiers uniquement : repository , récupération/téléchargement. Bon, ça semble être le meilleur, peut-être n’est-il pas exactement complètement parfaitement éventuellement définitivement objectif ? mais ma foi, c’est vrai que coté gestion de dépendance c’est mieux que Maven :

  • Gestion du nommage organisation / nom / (branch : OK, ça sert a rien de son propre aveu :-) ) / version / (métadonnée : ca ca peut servir : ex : dépendances différentes en fonction de target – PC, Unix)
  • Multi artefact : c’est vraiment le point le plus intéressant, Ivy permet de définir des configurations de dépendances et de les nommer, on peut ensuite associer ces config à des publications d’artefacts. On a donc un niveau supplémentaire de “configuration” possible pour les artefacts, et on peut en définir plusieurs. Le mieux pour comprendre c’est là → Ivy Configuration
  • La gestion des dépendances :
    • interne : on ajoute une visibilité “public” sur les conf définie précédemment -> magique !
    • externe : on ajoute une visibilité “public” sur les conf définie précédemment -> magique again ?
    • pas de concept runtime : Ivy s’occupe des dépendances ! donc pas de contingences existentialistes

Et maintenant OSGI !

OSGI est déjà plus restreint : on se concentre sur le runtime et sur Java. L’idée est de permettre aux classloader de différents modules (bundles) de se “référencer” entre eux. Cela permet dans un module donné de”chercher et trouver” les classes Java “dont on dépend”. On ne couvre clairement pas la même partie du cycle de dév que Maven/Ivy mais il y a tout de même une gestion de dépendances avec :

  • Gestion du nommage nom (souvent nom module = nom package “parent”) / version
  • Mono artefact : un jar point barre,
  • La gestion des dépendances d’un module peut être à usage :
    • externe : et c’est tout !!

En conclusion,

Ivy/Maven : c’est générique (i.e pas que pour Java), ça couvre le cycle complet : build->run. OSGI ne s’occupe que de gérer les dépendances entre API.

Je suis un peu resté sur ma faim sur la comparaison Maven/Ivy, on sent bien que le niveau supplémentaire de configuration de dépendances qu’apporte Ivy donne une flexibilité supplémentaire. Mais ceci dit, lorsqu’on met en place cette flexibilité dans un système de build (ant), n’est ce pas la porte ouverte :

  • à un nb de config exponentielles que plus personne ne comprends ?
  • à des config mortes que personne n’utilise ?

C’est le genre d’ouverture que Maven prend soin à “verouiller” par sa config plus monolithique (OK, j’arrete la pour les métaphores sur les portes …).

L’aspect configuration “public/privé” d’Ivy qui reproduit le paradigme d’encapsulation au niveau des modules est aussi très intéressant et la aussi on sent bien la puissance et la souplesse du concept. D’ailleurs, je me demande bien pourquoi Maven n’utilise pas Ivy en interne pour la gestion de dépendances. >:-)

Voici les slides de la soirée :

Juste une remarque concernant la session : un micro permettrait de mieux entendre l’intervenant !

Merci au Toulouse JUG pour cette session !!

This entry was posted in Divers and tagged , , , , , , . Bookmark the permalink.

2 Responses to Ivy, Maven, OSGI : gestion des dépendances au JUG Toulouse

  1. Gael Blondelle says:

    Yep, bien d’accord, faut qu’on équipe le JUG d’un micro. Je pense que ce sera fait pour la rentrée.
    Bonne nouvelle, pour l’Eclipse Party à l’N7, la grande salle est sonorisée…

  2. La présentation était intéressante mais très orienté vers la conclusion (à savoir mixer osgi pour ivy).

    Pour ma aprt je pense que le gros problème d’Ivy c’est Ant, je n’ai jamais vu un script Ant “developer-friendly”
    Et le seul apport de ivy par rapport à Maven est l’ajout des dépendances transitives conditionnés (un sacré casse-tête en perspective pour 1% de cas d’utilisation), problème facilement contournable avec Maven….

    Quand on voit tout ce que Maven fait à côté il n’y a vraiment pas photo

    Il aurait été aussi intéressant de parler de Tycho le pont entre Maven et OSGI d’Eclipse….

    Il faudrait vraiment que les gens arrêtent avec Ant. :D

Leave a Reply