Equinox p2 build and consumption

This document review the implication of p2 on what/how people build and how the consumption of the build output is affected.

Items that are being produced today	Same items in the context of p2
Plugins / features ready to run, referred as FTR. FTRs are used in the following ways: a) Unzipping, and running with -clean b) Creating ‘products’: b.1) by extracting in a links folder b.2) by unzipping on top of an eclipse install and rezipping b.3) by using pde packager c) Creating bigger FTRs c.1) by unzipping and rezipping c.2) by using packager d) Replacing thing in an existing base	With p2, FTR should preferably contain a content.xml. The motivation is to have consistency among the IUs that are being used when installing from a repo or not. This also avoids problems if the metadata generator evolves and produces different IUs since what could have been published.   a) This is supported by the drop-ins folder support. We need to ensure that it works appropriately when there is a content.xml. There are some restrictions since the content.xml could apply, therefore it is recommended for people to use a links folder structure rather than wild unzipping. b) Because of the p2 folder and the bundles.txt at the root of the product, and the content.xm, some of these scenarios become non-trivial, since the bundles.txt has to be created, the content.xmls could collide if multiple things were being unzipped. But let’s review the details b.1) This scenario does not change. The initial startup of the application will discover the content of the links folder and all p2 data structures (bundles.txt, p2 folder) will be updated appropriately. b.2) Because of the p2 metadata and the bundles.txt at the root of the product, and the content.xml, this scenario becomes non-trivial (there may be some answers from the shared install scenario). The current recommendation here is to use links folders (b.1). It is a change, but it actually represents an improvement since things can just be dropped. b.3) In this case the packager becomes a provisioning operation and nothing special has to happen. What happens when no content.xml exist? c.1) The only difficulty here is on merging the content.xml. However this should be doable by running the repository mirroring tool. What happens when no content.xml exist? c.2) In this case the packager also relies on the repository mirroring tool. What happens when no content.xml exist? d) This will be supported with the generation of patch metadata.
Update sites d) the update site is directly published for users to connect to. e) the update site is zipped and published for the user to download and use as a local site	Both scenarios are supported by producing appropriate p2 metadata as part of the build.
Eclipse-based products and how they are built f) product build in PDE g) adding a few things on top of eclipse (e.g. WTP all in one, EPP packages) h) homebrewed i) eclipse base + links folder containing plug-ins in a runnable form	Products need to have a corresponding IU (it aggregates the features, the plugins and the various configuration bits). f) product build needs to be made p2 aware to produce the product IU and also create the product by invoking a p2 operation. g) same difficulty than b.2. The recommended way is to use a provisioning operation h) the way to go is to provide the various archives of the product, a .product file and invoke a p2-izer operation. May not be supported immediately. i) See b.1.