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

Difference between revisions of "Equinox p2 Shared Install Plan"

(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 ...)
 
(→‎Open Issues)
 
(15 intermediate revisions by the same user not shown)
Line 8: Line 8:
 
* NO:
 
* NO:
 
** load shared bundles.txt
 
** load shared bundles.txt
−
* YES:
+
* YES:  
−
** is it newer than the shared one?
+
** is the user bundles.txt newer than the shared one?
−
*** YES:
+
*** 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
 
**** attempt to load it
 
***** SUCCESS:
 
***** SUCCESS:
Line 22: Line 22:
 
== Provisioning Operation ==
 
== Provisioning Operation ==
  
−
* are we running from the shared profile?
+
* materialize profile from running bundles.txt (and metadata repositories on disk for root IU inference)
−
* YES:
+
* Notes:
−
** display shared profile
+
 
** no manipulation allowed for shared IUs
 
** 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 ==
 
== Open Issues ==
  
−
* how do we mark shared IUs as such in the user profile?
+
* 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 =
 
= Scenario:  install from Linux distribution packages =
Line 44: Line 40:
 
== Disk layout ==
 
== Disk layout ==
  
−
* launcher:  /usr/bin/eclipse (ideally this is the actual launcher and not a wrapper script)
+
See below under startup.
−
* 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 ==
 
== Interesting stuff ==
  
−
* each RPM representing an "application" or a "product" (ie. something user-visible like an IDE or RSSOwl) will ship a profile
+
* both "products" (ex. Eclipse SDK, RSSOwl) and "add-on" RPMs (ex. CDT, Mylyn, RSSOwl extension) will include their own metadata repository
−
* 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 ==
 
== "product" startup ==
  
−
* read "product" bundles.txt
+
* only difference from above is that shared bundles.txt is split among base product and any add-ons
−
* new metadata repositories installed?
+
 
−
* YES:
+
Example:
−
** concatenate "product" bundles.txt and generated one of new stuff
+
 
−
** can it run?
+
Eclipse SDK (a "product"):
−
*** YES:
+
<pre>
−
**** do <user.home> stuff but try to merge with shared stuff always "winning"
+
/usr/bin/eclipse
−
**** write out aggregate shared bundles.txt and profile (in separate thread?)
+
/usr/share/eclipse/bundlepool/(lots of stuff)
−
**** update user profile with new aggregate stuff
+
/usr/lib/eclipse/fragmentbundlepool
−
*** NO (this should *not* happen):
+
/usr/share/eclipse/p2/bundles/sdk.txt
−
**** load old "product" bundles.txt
+
/usr/share/eclipse/p2/metadataRepositories/sdk.xml
−
**** perhaps mark MR as having bad stuff?
+
</pre>
 +
 
 +
CDT (an IDE "add-on"):
 +
<pre>
 +
/usr/share/eclipse/bundlepool/*cdt*
 +
/usr/lib/eclipse/fragmentbundlepool/*cdt*
 +
/usr/share/eclipse/p2/bundles/cdt.txt
 +
/usr/share/eclipse/p2/metadataRepositories/cdt.xml
 +
</pre>
 +
 
 +
RSSOwl (a "product"):
 +
<pre>
 +
/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
 +
</pre>
 +
 
 +
CoolThingy (an RSSOwl "add-on"):
 +
<pre>
 +
/usr/share/rssowl/bundlepool/*coolthingy*
 +
/usr/lib/rssowl/fragmentbundlepool/*coolthingy*
 +
/usr/share/rssowl/p2/bundles/coolthingy.txt
 +
/usr/share/rssowl/p2/metadataRepositories/coolthingy.xml
 +
</pre>
 +
 
 +
* aggregate "product"'s /usr/share/<product>/p2/bundles/*.txt
 +
* do <user.home> stuff as above
  
 
== provisioning operation ==
 
== provisioning operation ==
Line 77: Line 95:
 
== Open Issues ==
 
== Open Issues ==
  
−
* as above, how do we mark shared IUs as such in the user profile?
+
* as above, how do we mark shared IUs as immutable?
 
* can we split the install into /usr/lib, /usr/share, /usr/bin, etc.
 
* 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
+
* 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?
−
* we will need a custom configurator that deals with the workflow described above
+
* is the profile materialization (for provisioning operations an UI presentation) acceptable?
−
* how will we deal with concurrency if the profile is currently being run?
+
* will this still allow distributions to split up SDK by feature?  I think so ... maybe we'll have a bundles.txt per feature
  
 
== Pros ==
 
== Pros ==
Line 90: Line 108:
 
== Cons ==
 
== Cons ==
  
−
* startup cost when new stuff installed (will be rare, though)
+
* startup cost?
−
* complexity
+
* complexity?
−
* diverge from eclipse.org downloads
+
* diverge from eclipse.org downloads?
  
 
[[Category:Equinox p2|Shared Install]]
 
[[Category:Equinox p2|Shared Install]]

Latest revision as of 11:50, 17 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 (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?
Retrieved from "https://wiki.eclipse.org/index.php?title=Equinox_p2_Shared_Install_Plan&oldid=69021"

This page was last modified 11:50, 17 December 2007 by Eclipsepedia anonymous user Unnamed Poltroon.

Back to the top