Re[2]: [equinox-dev] workspace metadata and OSGi

[Peter Kriens <Peter.Kriens@xxxxxxxx>]

You are aware there is a Preferences service and also the UserAdmin
has a property database. Can't oversee how useful these are ...

Kind regards,

     Peter kriens

JM> This is a great topic and somewhat related to the User preferences work 
JM> and the work on separating out the install update info from the workspace.

JM> There really are two kinds of metadata in this context.  The stuff that is 
JM> related ot a particular install (e.g., some sort of bundle configuration 
JM> data like which port to use when connecting) and data related to a 
JM> particular runtime context (e.g., the JDT core index files for the 
JM> projects/jars in a particular workspace).  The former fits well into the 
JM> current OSGi implementations as they seem to have a bundles area where 
JM> they install bundles and in there each bundle has a "data" area.  This of 
JM> course does not work for the workspace-specific info.

JM> Some implementations allow you to start up and spec a different meta area 
JM> for each run.  We could spec a different meta area for each workspace but 
JM> since this is also where the framework keeps track of installed bundles, 
JM> we are back in the current situation that Eclipse has where plugins are 
JM> installed into a particular workspace.

JM> We should look at what the install/update folks have in mind for solving 
JM> this (Dejan, can you comment) as well as the usecases etc in the user 
JM> preferences area.
JM> Jeff

 




JM> Rafael Chaves/Ottawa/IBM@IBMCA
JM> Sent by: equinox-dev-admin@xxxxxxxxxxx
JM> 07/24/2003 12:08 PM

 
JM>         To:     equinox-dev@xxxxxxxxxxx
JM>         cc: 
JM>         Subject:        [equinox-dev] workspace metadata and OSGi




JM> Hello, 

JM> Eclipse has its own concept of metadata area (a .metadata directory inside 
JM> the workspace), which is where the platform configuration  (the list of 
JM> currently enabled plug-ins), the platform log, and plug-ins'  state are 
JM> stored. 

JM> The concept plug-in state location is equivalent to OSGi bundle's 
JM> persistent storage area, which exact location is completely specific to 
JM> the OSGi implementation. 

JM> I would say that with Eclipse running on OSGi, we should keep the platform 
JM> metadata area inside the workspace location, while plug-ins metadata would 
JM> be stored inside their persistent storage areas. 

JM> Pros: 
JM> - we will have a well known location for important data, such as platform 
JM> log and configuration. 
JM> - consistency between regular bundles storage areas and plugin bundles 
JM> state locations. 
JM> - no changes required on the OSGi implementation (although it would be 
JM> great if the recommended OSGi implementation for running Eclipse could use 
JM> the same metadata root and store their internal state there too). 

JM> Cons: 
JM> - plugin metadata exact location will depend on the OSGi implementation 
JM> being used - this is bad because it makes harder to diagnose problems that 
JM> require access to plug-ins metadata;. 
JM> - metadata will be split in two different places, so it will be harder  to 
JM> clean up the metadata area when the user wants to start things from 
JM> scratch. 

JM> Any comments? 

JM> Rafael



-- 
Peter Kriens                              Mob. +46705950899