Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Equinox p2 Shared Install Plan
Revision as of 12:56, 6 December 2007 by Unnamed Poltroon (Talk) (New page: = Scenario: read-only de-compressed upstream download = Eclipse installed read-only in <location> (say, '''/opt/eclipse''' or '''C:\Program Files\Eclipse''') == Startup == * check for ...)
Contents
Scenario: read-only de-compressed upstream download
Eclipse installed read-only in <location> (say, /opt/eclipse or C:\Program Files\Eclipse)
Startup
- check for <user.home>/.eclipse/p2/bundles.txt
- NO:
- load shared bundles.txt
- YES:
- is it newer than the shared one?
- YES:
- attempt to load it
- SUCCESS:
- run, yay
- FAIL:
- run shared bundles.txt
- present some sort of notice to user (upon startup?)
- SUCCESS:
- attempt to load it
- NO:
- reconcile
- YES:
- is it newer than the shared one?
Provisioning Operation
- are we running from the shared profile?
- YES:
- display shared profile
- no manipulation allowed for shared IUs
- additional bundles allowable
- create user profile as copy of shared profile (and additional IUs)
- write user profile to <user.home>/.eclipse/p2
- NO:
- display user profile
- no manipulation allowed for shared IUs (even if in user profile)
Open Issues
- how do we mark shared IUs as such in the user profile?
Scenario: install from Linux distribution packages
Note 1: I'm going to say "rpm" here but I really mean any distribution package Note 2: actual paths are negotiable; I just wanted to get some potentials down
Disk layout
- launcher: /usr/bin/eclipse (ideally this is the actual launcher and not a wrapper script)
- bundlepool: /usr/share/eclipse/p2/bundlepool (could remove p2 from name, doesn't really matter)
- fragments: /usr/lib (or /usr/lib64) /eclipse
- local repos: /usr/share/eclipse/p2/repositories (/metadataRepositories , /artifactRepositories (pointing to bundlepool)) ... see below
- profiles: /usr/share/eclipse/p2/profiles (one sub-directory per profile)
Interesting stuff
- each RPM representing an "application" or a "product" (ie. something user-visible like an IDE or RSSOwl) will ship a profile
- there will be a common bundlepool for all bundles
- "add-on" RPMs (ex. CDT, Mylyn, RSSOwl extension) will include their own metadata repository (maybe the SDK too?)
"product" startup
- read "product" bundles.txt
- new metadata repositories installed?
- YES:
- concatenate "product" bundles.txt and generated one of new stuff
- can it run?
- YES:
- do <user.home> stuff but try to merge with shared stuff always "winning"
- write out aggregate shared bundles.txt and profile (in separate thread?)
- update user profile with new aggregate stuff
- NO (this should *not* happen):
- load old "product" bundles.txt
- perhaps mark MR as having bad stuff?
- YES:
provisioning operation
- same as in above situation
Open Issues
- as above, how do we mark shared IUs as such in the user profile?
- can we split the install into /usr/lib, /usr/share, /usr/bin, etc.
- we will probably need a custom MetadataRepositoryManager to work with bundle .xml files
- we will need a custom configurator that deals with the workflow described above
- how will we deal with concurrency if the profile is currently being run?
Pros
- no %post fragility
- always correct, always starts up (well, unless base bundles.txt gets corrupted somehow)
Cons
- startup cost when new stuff installed (will be rare, though)
- complexity
- diverge from eclipse.org downloads