Re: [equinox-dev] workspace metadata and OSGi

["Rafael Chaves" <Rafael_Chaves@xxxxxxxxxx>]

In my original message, I was assuming
that bundle persistent storage areas and plugin state locations should
be the same. Jeff convinced me that that does not need to be true. We could
keep separated locations for the persistent storage area (provided and
controlled by the OSGi implementation) and the plug-in bundle state location
(provided by the Eclipse platform). 

In the cases of Update and Help, they
could use the bundle persistent storage area (since it is not workspace
specific), which is available through the BundleContext API. This location
is guaranteed to 
be writable. But it is not the Eclipse
install location. We still need to sort out  the details about how
the install/update mechanism will integrate in the new picture.

Rafael

Dejan Glozic 24/07/2003 12:37 PM

To:        Jeff McAffer/Ottawa/IBM@IBMCA         cc:        equinox-dev@xxxxxxxxxxx, Rafael Chaves/Ottawa/IBM@IBMCA, Dorian Birsan/Toronto/IBM@IBMCA         From:        Dejan Glozic/Toronto/IBM@IBMCA         Subject:        Re: [equinox-dev] workspace metadata and OSGiLink

Update is definitely going to remove
its state from the workspace metadata. It just does not make sense to link
data that relates to the application as a whole (i.e. features that are
currently installed, installation history etc.) to workspace data (projects
etc.). We had nothing but grief due to this.

We don't know where this 'application-specific'
metadata location will be. We are currently pursuing our own implementation
for the sake of making some progress, but are willing to switch to whichever
general strategy for storing application-specific state we choose. However,
we do have certain requirements for this location. This is what we plan
to do now:

1) We will store the state relative
to the 'eclipse' directory if possible
2) If this directory is read-only OR
if shared install is desired (using command line argument -shared), we
will store the state in <user.home>/<application-id> where
<user.home> is unique for each local user, and <application-id>
is the one defined in .eclipseproduct marker file.
3) The corollary of 1) and 2) is that
Update state will be in a well known location relative to the Eclipse application
(unlike today where there can be unlimited number of workspaces). This
is important for the native installers/uninstallers - they will be able
to clean up the shared state (if found).

Regards,

Dejan Glozic, Ph.D.
Manager, Eclipse Platform Components
D2/MY7/8200/MKM
IBM Canada Ltd.
Tel. 905 413-2745  T/L 969-2745
Fax. 905 413-4854

Jeff McAffer 07/24/2003 12:25 PM

To:        Rafael Chaves/Ottawa/IBM@IBMCA, Dejan Glozic/Toronto/IBM@IBMCA         cc:        equinox-dev@xxxxxxxxxxx         From:        Jeff McAffer/Ottawa/IBM@IBMCA         Subject:        Re: [equinox-dev] workspace metadata and OSGiLink

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