|[p2-dev] Eclipse Development and Build Patterns|
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:-
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:-
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.