Re: [equinox-dev] workspace metadata and OSGi

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

I'm not sure about the use of "application" so I will use "install", "configuration" and "instance" 
        install = location(s) where features/plugins are put on disk
        configuration = a descriptoin of a set of features/plugins which form a (hopefully) coherent set of function.  configurations point to installs and may subset them.
        instances = runtime contexts for a particular configuration.  You can have many instances for a given configuration. = roughly workspace but avoiding that term is good too.

It happens that in the current world the configuration == instance  in a one to one relationship.  Thus the problems we have.

Going forward, consider ...

Install/update can lay down features/plugins/ubndles in the "install" location. If it is running in the target configuration, it can add the new function to that configurationalso update the configuration to know about the newly installed function.  If you are installing into other configurations then I/U can leave droppings so that when that configuration is run it notices and includes the new stuff.  Or of course you could run the other configs headless and get them to absorb the new components.

One of the challenges here is that I/'U does not have any knowledge or control over the location/layout of the configuration and instance locations.  These are things dictated by the runtime.

Jeff

Dejan Glozic 07/24/2003 05:37 PM

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

Rafael,

The real Update requirement is that the application-specific (as opposed to workspace-specific) persistent storage area is a) always writable and b) easy to find relative to the application it applies to. The requirement b) is driven by a need for external (non-Eclipse) tools and programs to scan for Eclipse products and be able to find the Update data (i.e. installation records) for those products. They need not be IN the product install tree but must be retreivable using a reasonable and repeatable lookup algorithm.

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

Rafael Chaves 07/24/2003 04:12 PM

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

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