Tags

, , ,

Afin de donner un début de réponse à la question posée dans mon dernier billet “Peut-on vraiment industrialiser l’installation d’Eclipse avec p2 ?“, voici un tour d’horizon des capacités et des manques de cette plateforme de provisioning, à travers l’utilisation du p2 agent.

L’interface graphique de cet agent donne un aperçu des capacités de p2. Nous verrons comment installer “from scratch” un SDK minimal ou une distribution Eclipse complète. Nous mettrons aussi en application le “bundle pooling” qui permet d’utiliser un référentiel de plugins, partagé par plusieurs instances d’Eclipse.

Commençons par télécharger l’agent. Sur la page des téléchargements Equinox, choisir par exemple la release 3.5.2. Le lien de téléchargement de l’agent p2 se trouve dans la section “Provisioning” de la page de téléchargement de cette release.

Téléchargement du p2-agent

Téléchargement du p2-agent

L’agent p2 est bien sûr une application Eclipse, donc son installation se fait de façon classique, en décompressant l’archive. On retrouve aussi l’habituel eclipse.exe, pour la version Windows.

L'interface du p2-agent

L'interface du p2-agent

La partie supérieure de l’interface présente les dépôts disponibles dans deux onglets. p2 distingue les Metadatas des Artifacts car il est capable de gérer les uns indépendamment des autres. Cela dit, en pratique, les dépôts sont habituellement mixtes et contiennent à la fois métadatas et artifacts. Par défaut, deux dépôts sont déclarés dans la vue Metadata Repositories :

La partie inférieure présente les profils de provisioning. Par défaut il n’y en a qu’un, nommé EquinoxProvisioningUI, qui correspond à l’agent p2 lui-même. Le menu contextuel permet d’en créer de nouveaux.

L’interface peut sembler récalcitrante lorsque l’on tente d’explorer le contenu des dépôts. Il faut dans ce cas déclarer ces mêmes dépôts dans l’onglet Artifacts Repositories.

Voyons maintenant comment définir et installer des profils, à travers les deux exemples suivants :

  • d’une part un SDK Eclipse 3.6M6 minimal,
  • d’autre part une distribution Galileo (Eclipse 3.5) “for Java EE Developers” intégrale.

Pour commencer, il nous faut déclarer – dans les deux onglets Metadata et Artifact Repositories – les dépôts relatifs à nos versions cibles :

Déclaration des dépôts Helios Milestones et Galileo EPP

Déclaration des dépôts Helios Milestones et Galileo EPP

Ensuite, créer un premier profil : clic droit dans la vue Profiles > Add profile… puis saisir les informations relatives au nouveau profil :

Dialogue "Ajouter un profil"

Dialogue "Ajouter un profil"

Attention au champ “Bundle pool location” ! Le laisser vide engendre l’utilisation du bundle pool par défaut, c’est-à-dire celui qui se trouve dans le dossier d’installation de l’agent p2 lui-même.
Pour ne pas utiliser de bundle pool, ou plutôt placer le bundle pool dans le dossier d’installation d’Eclipse, comme pour une installation classique, il faut indiquer explicitement le dossier d’installation. Dans notre exemple, il aurait donc fallu indiquer C:testeclipseSDK. Ici, l’objectif est de partager les bundles entre nos deux Eclipse cibles, donc nous choisirons un dossier spécifique : C:testbundlepool.

Une fois le profil créé, on y ajoute le SDK en y faisant glisser l’unité d’installation “org.eclipse.sdk.ide” – dans la version souhaitée – depuis le dépôt Helios.

Ajout du SDK au profil

Ajout du SDK au profil

L’installation démarre immédiatement. On retrouve alors le principe habituel de mise à jour : vérification de la compatibilité et des dépendances, confirmation de l’installation, présentation de la licence, puis téléchargement des bundles et installation proprement dite.

La structure de fichiers obtenue à l’issue de l’installation est la suivante :

Structure de fichiers provisionée

Structure de fichiers provisionée

Le dossier d’installation eclipseSDK est très léger (263 ko) car il ne contient aucun plugin, ceux-ci étant fédérés par le “bundle-pool”.

Créons maintenant un second profil pour notre distribution Galileo “for Java EE Developers”, en réutilisant le même bundle-pool :

Création du profil eclipseJEE

Création du profil eclipseJEE

L’unité d’installation qui représente la distribution Galileo Java EE se trouve dans le dépôt Galileo “EPP Packages Repository” et se nomme “org.eclipse.epp.package.jee.feature.feature.group”.

Voici le résultat obtenu à l’issue de cette seconde installation :

Etat de l'agent et du système de fichier à l'issue de l'opération

Etat de l'agent et du système de fichiers à l'issue de l'opération

Il est bien évidemment possible de compléter ces profils en y ajoutant d’autres plugins, par le même procédé.

Ces essais donnent une idée du fonctionnement général de p2.
Mais quelques tests supplémentaires permettent également de se rendre compte que l’agent p2 ne répond pas au besoin d’industrialisation qui fait l’objet de ce billet. Notamment, ses limitations excluent la possibilité d’utiliser cet outil pour centraliser la configuration d’un environnement projet de façon à le répliquer sur un parc de machines :

  • L’agent ne permet pas de provisioner un profil à plusieurs endroits, ni de provisioner un profil sur un réseau.
  • Il ne permet pas de déplacer ou de renommer un Profil.
  • Les éléments s’installant par glisser-déposer, il n’est pas possible de définir une configuration complète avant de lancer l’installation, et encore moins de lancer plusieurs installations en parallèle.

Le principal avantage de l’agent p2 réside dans sa capacité à gérer le bundle-pooling. Il peut donc servir à gérer un pool d’instances locales d’Eclipse, sachant que si l’une de ces instance est amenée à être déplacée, elle devra ensuite évoluer indépendamment de l’agent.

Au delà de l’agent, force est de constater que p2, malgré tous les bénéfices qu’il apporte par rapport à son prédécesseur l’Update Manager, ne répond aujourd’hui qu’en partie à la problématique de provisioning d’environnements de développement.

En effet, l’outillage disponible ne permet pas d’installer autre chose que des bundles OSGI. Or un environnement de développement est composé de plusieurs autres composants : JVM, serveur, fichiers de configuration, distribution maven, etc.

De même, le workspace Eclipse est un composant critique, non géré par p2, dont le provisioning aurait pourtant une forte valeur ajoutée : configuration de l’encodage, du compilateur, des actions automatiques à la sauvegarde, de checkstyle, du gestionnaire de sources, import des projets, etc.

En conclusion, je dirais que p2 n’est pas la solution miracle à cette problématique de provisioning d’environnements de développement, mais il répond tout de même à une partie importante du problème. L’agent p2, quant à lui, n’est adapté qu’à une utilisation locale donc mono-poste. A ce niveau, la version community de PULSE, par exemple, est plus intéressante car bien plus complète et propose notamment le provisioning de Workspace.

Dans un prochain billet, je présenterai le p2 director qui fournit plus de souplesse que l’agent p2 et dont le mode d’utilisation, en ligne de commande, ouvre d’autres perspectives.

Advertisements