Revision as of 14:59, 6 December 2007

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 the user bundles.txt 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?)
    • NO:
      • reconcile

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?

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