For years, Eclipse has been shipped along with a component called the "Update Manager", 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 these needs. 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. p2 is still a very young project, and may not seem mature enough for industrial usage. It is still not 100 percent reliable 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. Benjamin Cabé Eclipse Expert – Anyware Technologies

Why not mention companies that have been delivering OSGi profiles on P2 already - like Genuitec? Pulse is a stable, proven platform for delivering OSGi profiles, and it's used commercially both by general public and private-branded platforms. It's been delivering for over a year (see the TSS posts: http://www.theserverside.com/news/thread.tss?thread_id=48755 and http://www.theserverside.com/news/thread.tss?thread_id=47692 - posted in November 2007). I'd think - and hope - that someone interested in propagating P2 itself would consider the success stories of all vendors, instead of using only companies still in the development phase as examples. P2 is used by Pulse to deliver Eclipse 3.3 profiles, too - something p2 in and of itself can't do yet. (Genuitec adds something - I don't know what - to make this happen for Pulse.)

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.

Excellent statement - but IMO, as a Pulse user, I'm not sure there's "currently no real sustainable alternative."

Why not mention companies that have been delivering OSGi profiles on P2 already ... I'd think - and hope - that someone interested in propagating P2 itself would consider the success stories of all vendors, instead of using only companies still in the development phase as examples.

Indeed! EclipseSource (formerly Innoopract and Code 9) has been shipping its production ready, p2-based Yoxos Eclipse provisioning system and distribution for some time. There are a number of other companies such as IBM, Wind River and others that base their product delivery story on the technology. As a member of the p2 team it is gratifying to see this adoption.

Excellent statement - but IMO, as a Pulse user, I'm not sure there's "currently no real sustainable alternative."

I'd also question the lack of alternatives...given Newton (http://newton.codecauldron.org) has been able to deploy OSGi applications to remote machines and has been able to do this for 3 years. Last year I gave a presentation at EclipseCon entitled "Building Large Scale OSGi applications" where I highlighted the fact that Infiniflow (http://www.paremus.com) - our commercial product based on Newton has been used in a proof of concept to deploy OSGi bundles to over 800 instances in an enterprise environment.

Excellent statement - but IMO, as a Pulse user, I'm not sure there's "currently no real sustainable alternative."

I also disagree with the statement that there is "no real sustainable alternative". ProSyst's mPower Remote Manager (http://www.prosyst.com/products/back_end_mgmt.html) is used for the deployment and management of OSGi systems for 7 years now. For example, it is successfully used in a productive system to manage 60,000 OSGi targets.

BTW, a URL for p2, for those interested: http://wiki.eclipse.org/Equinox_p2

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.

With virtualization do we even need hot deployment during production? You'd bring up a whole new image of your application. Test that its running ok, then flip a switch to start routing packets to the new image. Sure, you'd still want hot-deployment during development, but production systems are and always were a different ballgame. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com

I very much agree with Bill. Hot deployment always seems to be an often hyped feature of app servers. It's wonderful for development, however, I am hard pressed to consider a situation where I would risk the stability of a production server for the time saved on hot deployment. It seems safer and saner to bring up another instance (whatever your methodology) and flip at the routing layer. I suppose someday we might come to see java app servers as mini OS spaces and I'll feel as comfortable redeploying as I feel with restarting a process. If P2 and osgi get us in that direction, all power to them. -Adam Malter

Hot-deployment is sexy and demos well. Its great for development time or for collaborative development on shared servers. We have used it to great effect in semi-embedded scenarios. Having said that, I'm not all that fond of it as a solution in scalable server situations. One of the hidden gems though is the ability to define and manage configurations using technology such as p2. The server configuration that you spin up to replace/update an existing one had to come from somewhere. How was it defined? How was it provisioned? Could you record/version that? replicate it in other locations/nodes? These are the really cool but ultimately less sexy uses for p2.

Sounds like some great fodder for OSGI DevCon running at EclipseCon in a few weeks... http://eclipse.org/go/OSGIDEVCON - Don