Update Manager and p2 Compatibility

This page will be used to keep track of initial thoughts on the compatibility between p2 and update manager.

Problems with the platform.xml

• inferrence of bundle name from the file path
• there isn't a way to set the start level for a bundle which isn't on the osgi.bundles list
• ditto for the initial state (started or not)
• p2 explicitly lists all bundles, you don't get auto-matic site discovery, have to install the directory watcher bundle for this
• directory watcher can be run at anytime...no only at startup
• look at the platform.xml and create artifact/metadata repositories for it

Scenerios

• install a feature from an old-style update site that doesn't have p2 metadata
  • don't do it
  • (have 2 UIs) use old code path, spoof up metadata for what we downloaded or hack update to generate md for what we are downloading
  • generate p2 metadata on the fly for what is on the update site

Misc

• update core APIs : install this feature
  • can we say we don't support this?

• have a server with p2 data and 3.3 style and someone installs a feature with the old update UI

• I have the SDK installed by p2 and I want to download a feature which requires the RCP but I don't know about the RCP feature
  • do we keep feature information around?
  • how do features appear in PDE?
  • how much tooling do we have for groups/features?

• do we delete the update.ui bundle from the SDK for 3.4?
  • if so, then we need to be able to handle old update sites, etc from the new ui

• can features and IUs have dependancies on each other?
• what level of integration do we seek?
• do we ever want to reconcilate 2 worlds?
• can update manager just install things and we have a hook/listener in the update core?
• maybe the directory watcher can update the bundles.txt for things which have been installed by the update manager apis
• low bar: we should still be able to reconsume things from an update site
• what if the platform configuration updated the bundles.txt?