[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] workspace metadata and OSGi
- From: Peter Kriens <Peter.Kriens@xxxxxxxx>
- Date: Thu, 24 Jul 2003 21:32:47 +0200
- Delivered-to: email@example.com
- Organization: aQute
You are aware there is a Preferences service and also the UserAdmin
has a property database. Can't oversee how useful these are ...
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> 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> Subject: [equinox-dev] workspace metadata and OSGi
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> 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> - 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> - 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> Any comments?
Peter Kriens Mob. +46705950899