Tags

, ,

Comme l’indique Benjamin Cabé dans son article “Déployer avec Equinox p2” (version anglaise ici sur Eclipse Zone), P2 était trop jeune en février 2009 pour être utilisé dans une logique d’industrialisation des déploiements. Mais qu’en est-il maintenant, un an plus tard ?

Cette plateforme de provisioning apporte de réelles solutions aux problématiques d’installation de produits OSGI, à commencer par les applications Eclipse RCP.

Mais ce qui m’intéresse particulièrement, c’est une autre des promesses de P2 : l’installation industrialisée des environnements de développement Eclipse eux-mêmes. L’intérêt est multiple : gain de temps, outils et configurations identiques pour tous les membres d’une équipe projet, gestion centralisée des mises à jour, pérennité des “dispositifs qualité” mis en place (voir mon précédent article à ce sujet : L’importance d’automatiser l’installation et la configuration des environnements de développement pour réduire la dette technique), etc.

Dans ce contexte de provisioning industriel, les apports de P2 sont indéniables :

  • Capacité d’installer Eclipse “from scratch”, contrairement à l’Update Manager, son prédécesseur, qui permettait uniquement de personnaliser Eclipse après son installation.
  • Possibilité de définir des profils d’installation c’est à dire des configurations de plugins personnalisées : telle version d’Eclipse plus tels et tels plugins.
  • Mise en commun des bundles Eclipse dans un référentiel local partagé par plusieurs instances d’Eclipse: le bundle pooling. Cette fonctionnalité permet ainsi d’économiser de l’espace disque et de la bande passante en réutilisant les composants déjà installés.

En pratique, le manque de maturité de P2 et le manque de clarté dans les nombreux outils disponibles rendent la tâche relativement délicate.

P2 a néanmoins un fort potentiel que j’approfondirai prochainement dans ces pages à travers une présentation de quelques uns des outils qui lui sont associés.

Advertisements