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.
Equinox/p2/Shared Install
Contents
One of the work items on the Equinox p2 Juno plan is to improve the Shared Install story. This wiki page will be used to collect a list of current problems related to the Shared Install story, as well as potential solutions and even brain-storming new and crazy ideas for improving the situation.
The umbrella bug report for the plan item is Bug 358471.
Current Issues
Missing Repositories (Bug 249133)
Problem - Currently when you start Eclipse as a user, you are presented with an empty list of update repositories even though the admin user has set them in the base install.
Discussion/Ideas
- Transient repositories - read parent's repos but consider them transient and don't write them out
- Cascaded repositories
- RepoMgr loads from shared area and user's area and always writes everything to user area
User's Locally Installed Features Lost on Base Update (Bug 304132)
Problem - If the user is running in shared install mode and has their own features installed and the admin user updates something in the base location, then the user's locally installed features are lost.
Discussion/Ideas
- Keep separate metadata for the base location and the user location. At start up p2 reads both sets of metadata and merges them.
- The user metadata should not contain the parts from the base location (unless these parts are actually installed in both places)
User's Configuration Changes Lost Across Major Updates (Bug 329587)
Problem - The calculation of the default user's config area is based on the value in the shipped .eclipseproduct file, along with the hash of the install folder for the product you are running. If the value in this file is incremented with each release, a new configuration area will be chosen (by default) and user changes will be lost. Discussion/Ideas
Random Thoughts and Ideas
When discussing shared install and looking at some of the code, there are multiple places where we do the same things like calculate if we are in shared mode, calculate paths, etc etc. It would be a lot of work but one interesting idea would be to basically determine early on that we're in shared mode, create an object with the context that we need, and then pass that along/query it for information later. Kind of a global "shared mode" switch being flipped. It is unclear if this logic would be in a new bundle that somehow extended the current behaviour or something else.