Re: [equinox-dev] workspace metadata and OSGi

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

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

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

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

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

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

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

Hello, 

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

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

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

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

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

Any comments? 

Rafael