La dernière version d’Eclipse annoncée l’année dernière s’est accompagnée de l’émergence d’une nouvelle plateforme de provisioning baptisée p2.
Pendant des années, Eclipse a été livré avec un composant appelé Update Manager, qui permettait aux utilisateurs de mettre à jour leur environnement Eclipse -presque- sans effort. Cependant, au fil des évolutions successives, et en particulier avec l’arrivée de sa version 3.0, Eclipse est devenu bien plus qu’un simple environnement de développement : c’est désormais une véritable plateforme logicielle, basée sur Equinox (l’implémentation Eclipse du standard OSGi). Les besoins en terme de déploiement ne sont donc plus limités à l’installation et la mise à jour de simples plug-ins… Les concepteurs de logiciels basés sur Eclipse doivent pouvoir proposer un installeur de leur produit, qui nécessitera peut-être un gestionnaire de licences qu’il faudra également installer, … et p2 est la plupart du temps la solution à ce type de problématique.
p2: une plateforme de provisioning…
Pour être en mesure de provisionner tout type d’application, l’atout principal de p2 est de ne pas être exclusivement centré sur les environnements Eclipse, ni même sur les applications Java. Il s’agit d’un simple framework permettant de décrire des éléments à installer, ainsi que leurs dépendances. Ce framework vient avec des implémentations-type permettant d’installer des modules OSGi ou des produits RCP, mais guère plus. Il appartient ensuite aux vendeurs de logiciels qui souhaiteraient, par exemple, installer un exécutable Windows en même temps que leur application Eclipse RCP, d’écrire du code spécifique (en fait, un plug-in p2 !), pour réaliser cette installation correctement.
….en mesure de devenir le prochain standard de déploiement ?
Bien entendu, p2 est encore un jeune projet et peut ne pas sembler assez mature pour être utilisé dans une logique industrielle (pas toujours totalement fiable, outils parfois manquants, …), mais la qualité de cette première version est particulièrement prometteuse. Depuis sa sortie, p2 a su fédérer une communauté d’utilisateurs qui commence à le mettre à profit dans d’autres contextes que des projets purement Eclipse. Des entreprises comme Cloudsmith, EclipseSource, ou Anyware Technologies développent d’ores et déjà des outils basés sur p2 et IBM, entre autres, travaille activement à l’amélioration du noyau p2, ainsi qu’à la définition d’une véritable API.
L’adoption massive d’OSGi dans de nombreux environnements (technologies de runtime telles qu’Equinox ou RAP, serveurs d’applications comme Websphere ou Glassfish…) positionne p2 comme la solution la plus pertinente pour déployer des applications basées sur Eclipse, mais également toutes sortes d’applications scalables. En effet, dès qu’il s’agit de garantir une disponibilité importante des applications, il est indispensable de pouvoir installer ou mettre à jour des modules (parfois à distance) sans avoir à arrêter le système en cours d’utilisation.
Parce qu’il n’y a aucune alternative réelle pour des déploiements industriels —avez-vous déjà essayé d’utiliser Java Web Start pour installer autre chose qu’une application RCP basique? 😉 —, p2 s’imposera vraisemblablement comme la technologie standard de déploiement pour des systèmes hétérogènes.
Last year’s Eclipse release (Ganymede) came with a new provisioning platform called p2. For years, Eclipse has been shipped along with a component called the “Update Manager”, which allowed users to easily update their Eclipse installations. Nevertheless, year after year, and especially when Eclipse 3.0 came out, it has become much more than just an IDE: it is now a software platform, built on top of Equinox (the reference implementation of the OSGi specification).
Thus, deployment needs are not limited to installing and updating only plug-ins anymore. People building software on top of Eclipse need to be able to deliver an installer for their product, which may come with a license manager which needs provisioning too, they need to have their own UI for the updating process, … and p2 answers to virtually all these needs.
p2: a provisioning platform…
To be able to provision virtually everything, the main strength of p2 is to have no a priori knowledge of the way Eclipse plug-ins or even Java applications must be handled. It’s indeed a very light framework to describe the parts that are to be installed (the Installable Units), and how they depend on each other. p2 comes with some basic instructions about how an OSGi bundle or an Eclipse product should be installed, but nothing else.
It’s up to the software vendor who wants to deliver, let’s say, a Windows executable program (which may require adding keys to the registry, or icons on the desktop, for instance) together with its Eclipse RCP application, to write the code (in fact, a p2 plug-in!) to explain p2 how this particular Installable Unit should be handled when provisioned in a given system.
… and, the next deployment standard?
Of course, although p2 is still a very young project, and may not seem mature enough for industrial usage. It is still not 100% reliable yet and lacks tooling, but the quality of this very first release is still pretty high. Since it was released, p2 has started gathering a community which is leveraging p2 in other domains than just the Eclipse project itself. Software companies like Cloudsmith, EclipseSource and Anyware Technologies are already developing tools on top of p2 ; and IBM, among others, is working hard to improve the p2 core and design a clear API.
The massive adoption of OSGi in many different areas (Eclipse runtime technologies like Equinox itself or RAP, applications servers like Websphere or Glassfish, etc.) will definitely make p2 the smartest way to deploy not only Eclipse-based applications, but any sort of scalable application as well. Indeed, when high availability is an important requirement (in other words — almost always), then you need to be able to dynamically install new modules into the running system, update existing ones, sometimes even do this remotely.
Since there is currently no real sustainable alternative for industrial deployments – did you ever try to use Java Web Start for more than just a very simple Swing or RCP application? – p2 will probably come up as a de facto provisioning technology standard.
4 replies on “Déployer avec Equinox p2Equinox p2: Large Scale Deployment”
Salut,
AMHA, ce qui manque le plus à P2 actuellement c’est le tooling de développement (i.e. dans PDE).
PDE génère automatiquement les fichiers p2 nécessaires pour un update site, mais ça inlut pas les catégories ni le nom du site par exemple.
Salut Djo!
Je suis tout à fait d’accord avec toi!
Je pense que ce que tu veux dire c’est que l’export d’un produit ou d’une feature propose bien de générer des repositories p2 sans pour autant te laisser trop la main sur les catégories ou le nom du site, mais sache néanmoins que si tu continues à créer un projet “Update Site” à l’ancienne, il est tout à fait exportable sous forme d’un entrepôt p2 “sexy” ! 🙂
On peut également, même si c’est sans éditeur PDE pour l’instant, faire des choses très sympas grâce aux touchpoint advices (voir ici)
Bonjour,
Nous développons des applis RCP et nous souhaitons utiliser p2 pour faciliter nous le déploiement et la mise à jour.
Il est très important que l’application soit mise à jour avant utilisation. Pour cela, nous imaginons :
1. Lancer une tâche de mise à jour au démarrage du pc client (a priori les PC sont éteints la nuit…).
2. Lancer une tâche de synchro au lancement de l’appli RCP
Comment faire avec p2 pour atteindre cet objectif ?
Quels sont les pré-requis sur le poste cible ?
Quelles sont les possibilités d’intégrer cela dans un processus d’intégration continue ?
A titre d’information, nous utilisons Tycho + continuum pour construire nos plugins et notre product.
Bonjour,
je souhaite utiliser p2 pour distribuer non seulement des plugins/features que je développent mais aussi d’autres choses comme des binaires executables, des msi, … bref des choses qui ne sont ni des plugins ni des features ni des produits. Or je ne sais pas comment faire pour créer un I.U. and des touchpoints permettant de décrire ce qui peut etre installer, mis à jour. Je ne trouve pas trop de documentations ou d’exemples sur le sujet donc je suis preneur pour toute information…
Merci d’avance
P.S. j’avais suivi ta presentation a Eclipse Now You can 2008