Skip to main content

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.

Jump to: navigation, search

Equinox p2 Shared Install Plan

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 (when we enter this, the end goal is for the framework to be running at least all the bundles from the shared bundles.txt)
        • 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

  • materialize profile from running bundles.txt (and metadata repositories on disk for root IU inference)
  • Notes:
    • no manipulation allowed for shared IUs

Open Issues

  • how do we make shared IUs immutable?

Interesting stuff

The user bundles.txt lists all the bundles to run.

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

See below under startup.

Interesting stuff

  • both "products" (ex. Eclipse SDK, RSSOwl) and "add-on" RPMs (ex. CDT, Mylyn, RSSOwl extension) will include their own metadata repository

"product" startup

  • only difference from above is that shared bundles.txt is split among base product and any add-ons

Example:

Eclipse SDK (a "product"):

/usr/bin/eclipse
/usr/share/eclipse/bundlepool/(lots of stuff)
/usr/lib/eclipse/fragmentbundlepool
/usr/share/eclipse/p2/bundles/sdk.txt
/usr/share/eclipse/p2/metadataRepositories/sdk.xml

CDT (an IDE "add-on"):

/usr/share/eclipse/bundlepool/*cdt*
/usr/lib/eclipse/fragmentbundlepool/*cdt*
/usr/share/eclipse/p2/bundles/cdt.txt
/usr/share/eclipse/p2/metadataRepositories/cdt.xml

RSSOwl (a "product"):

/usr/bin/rssowl
/usr/share/rssowl/bundlepool/(stuff)
/usr/lib/rssowl/fragmentbundlepool
/usr/share/rssowl/p2/bundles/rssowl.txt (points to Eclipse bundles for dependencies)
/usr/share/rssowl/p2/metadataRepositories/rssowl.xml

CoolThingy (an RSSOwl "add-on"):

/usr/share/rssowl/bundlepool/*coolthingy*
/usr/lib/rssowl/fragmentbundlepool/*coolthingy*
/usr/share/rssowl/p2/bundles/coolthingy.txt
/usr/share/rssowl/p2/metadataRepositories/coolthingy.xml
  • aggregate "product"'s /usr/share/<product>/p2/bundles/*.txt
  • do <user.home> stuff as above

provisioning operation

  • same as in above situation

Open Issues

  • as above, how do we mark shared IUs as immutable?
  • can we split the install into /usr/lib, /usr/share, /usr/bin, etc.
  • will we need a custom configurator that deals with the split bundles.txt or should we have a variable like osgi.bundles.path where it looks for bundles.txt files and aggregates them?
  • is the profile materialization (for provisioning operations an UI presentation) acceptable?
  • will this still allow distributions to split up SDK by feature? I think so ... maybe we'll have a bundles.txt per feature

Pros

  • no %post fragility
  • always correct, always starts up (well, unless base bundles.txt gets corrupted somehow)

Cons

  • startup cost?
  • complexity?
  • diverge from eclipse.org downloads?

Back to the top