Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Update Manager and p2 Compatibility"
(→Misc) |
(→Problems with the platform.xml) |
||
| Line 2: | Line 2: | ||
===Problems with the platform.xml=== | ===Problems with the platform.xml=== | ||
| − | * | + | There are some problems with the current form of the platform.xml file. Here is a list of some of the things which come to mind. |
| + | * inference 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 | * 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) | * ditto for the initial state (started or not) | ||
| − | * p2 explicitly lists all bundles, you don't get | + | * p2 explicitly lists all bundles, you don't get automatic site discovery, have to install the directory watcher bundle for this |
* directory watcher can be run at anytime...no only at startup | * directory watcher can be run at anytime...no only at startup | ||
* look at the platform.xml and create artifact/metadata repositories for it | * look at the platform.xml and create artifact/metadata repositories for it | ||
Revision as of 14:31, 14 November 2007
This page will be used to keep track of initial thoughts on the compatibility between p2 and update manager.
Problems with the platform.xml
There are some problems with the current form of the platform.xml file. Here is a list of some of the things which come to mind.
- inference 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 automatic 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
Questions
- Are we shipping the Update Manager UI with Eclipse 3.4?
- Are we shipping org.eclipse.update.core.* with Eclipse 3.4?
- What is considered API in the update bundles? Yes, almost everything is marked as provisional but its been like that since 2.0 and if we don't offer some level of support then a lot of people may be broken.
- Once you install something with p2, can you go back to the UM UI? Can features reference IUs?
- Reverse scenario.
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
- People who are using the update.core APIs in headless applications.
- Running SDK with UM and p2.
- Install IU which represents (for instance) RCP via p2.
- Want to install a feature which depends on RCP via UM.
- Do we know that the RCP feature is installed and our dependency requirements are met?
Ideas
- Hook the update.ui bundle so it calls new p2 APIs.
- Have the update manger bundles operate as per Eclipse 3.3 and use the directory watcher bundle to notice changes and update the bundles.txt file accordingly.
- Might have to modify the directory watcher so it notices changes in the platform.xml file.
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?
- old ui + features -> install, update platform.xml -> bundles.txt?
- new ui + ius -> install, update bundles.txt -> platform.xml?
- In Eclipse 3.4, we will always start based on the bundles.txt.
- I have an old UM site with features, how do I install them?
- 1). old UM ui/core APIs
- bundles.txt
- platform.xml
- 2). p2
- generate metadata on the fly -> look at Maya, effeciency?
- install handlers - what do they have access to? life cycle? API?
- platform.xml
- still download the feature jars
- PDE is feature-aware
- 1). old UM ui/core APIs
- change update configurator to lay down a bundles.txt as well as the platform.xml
- like we have config scripts to update the bundles.txt file, we should have scripts which update the platform.xml file
- we need to ship features to handle the case where features on sites depend on it
- also to handle people who are developing against previous code bases
- features are listed only in the platform.xml, and the bundles are listed in both.
- platform.xml is our backwards compat trick
- need to maintain consistency between the 2 files
- do we want metadata for things installed by update manager
- baseline 0 - install something from an update site, restart eclipse, and have it be there. (eclipse starts from a bundles.txt)