Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[p2-dev] Eclipse Development and Build Patterns


Hi Folks,

I've been reviewing p2 and the PDE build process to understand how the two fit together.  As well as leveraging osgi server-side moving forwards we also have an existing (now) eclipse 3.4/p2-based product and I am not sure we are building it correctly.  I'm therefore seeking to clarify my understanding.  I've tried to boil this down a bit to make it consumable for others within my organization.  Maybe I have gone too far? 

By the way I've had a hard time finding much documentation out there.  There is some but it doesn't really answer all my questions.  Threfore if you think this is correct and you think others might find it useful I'd be happy to add it (or an expanded version of it) to the equinox-p2 wiki.

One other question.  What cvsroot can I find the p2 code under?

OK so here is my summation:-

Broadly speaking there are 3 ways to perform a pde build:-

  1. create a feature (set) and an update site (pde build.xml)
  2. create an eclipse application as a binary distribution (Eclipse SDK uses this method) (pde build.xml)
  3. create an rcp app as a binary distribution (pde buildProduct.xml)

For those wishing to deliver one or more components (as opposed to delivering a product) the feature build is the best alternative. Consumers can pull these new features into their eclipse applications using the "software updates" p2 UI.  For the publisher this saves worrying too much about p2, save generating metadata & artifacts for the update site - eclipse & its p2 agent will do the rest.

For those who must deliver a (p2-enabled) product they need to consider p2 during the build process. Pre-p2 it was just a case of running the pde build to create your bundles and features in an eclipse instance and zipping it all up.  Now you have to supply an extra set of p2 properties and perform some additional steps:-

  1. run pde build (as before but with new p2 properties; generate.p2.metadata et al) - the new result of this step is a p2 update site with an installable product IU
  2. use the p2 director to install the product IU (???in order to get a proper p2-enabled product with p2 profile in its registry that correctly reflects the product???)
  3. zip up the newly installed product ready for distribution

The hackers alternative

There is a "hackers alternative" to the pde-p2 build process. You can build your product using the same pde build as before and then rely on the reconciler.dropins  plugin's backward compatibility capability to provision any additional features it finds into the eclipse installation through p2.

The downstream implications of doing this are undetermined at the moment.

Many thanks

_Paul

 

Back to the top