Community
Participate
Working Groups
Even if there exist an extension point to provide a vendor-specific persistence provider, there is no way to use the provided persistence provider as the RSEPersistenceManager is hard-coded to use always the standard property file persistence provider (RSEPersistenceManager.getRSEPersistenceProvider()). If the extension point should be ever useful, vendors need to get the possibility to set the used persistence provider without modifying the code (in example via plugin_customizations.ini).
This is done as a temporary measure since there is (as yet) no mechanism for resolving what happens when more than one persistence provider is registered. It would be better to remove the extension point for now but keep the extension mechanism active so that it can be added back later.
I would vote for removing the extension point + the implementation. I think it is problematic to allow to replace the persistence provider as it may lead to bug reports we never will be able to track down or to resolve. However, it would be very important to make the property file persistence provider more configurable. Especially should it be possible to set a preference setting to store and restore the persistence under .metadata instead of being a workspace project. We have so much problems with the fact the RSE is using the workspace as state location ....
I agree that we should not have any extension points or API that we know is not working properly. Do we know of any users that would want to replace the persistence provider? If not (yet), then I think we'd better get rid of the extension point for 2.0, and probably reinstate it for our next release in a clean manner. Given that there are other requests to change the way how persistence is working, (persist in .metadata, associate with projects like Launches) it's probably good to not be bound to published APIs as of 2.0.
Proposed solution as discussed in the committer meeting from 2007-03-29: - Keep the extension point and related mechanism as it is a common and easy way to contribute persistence provider. Contributed persistence provider may used as well for imporing legacy persistence model into the current model. - For consistency reason, there can be only one active persistence provider which RSE is using for storing information about created hosts, filter pools and filters. Which one of the contributed persistence provider is the active one needs to be configurable on product level (plugin_customization.ini). The active persistence provider id will be a non-UI preference setting. - Sharing connections, filter pools and filters via the RemoteSystemConnections project directly is problematic is it has limitations. Committer prefer an explicit model of exporting and importing sharable information and associate them with projects for team sharing (like the standard Eclipse launch configurations).
Extending this in the future, and along the ideas that DaveM had in http://wiki.eclipse.org/index.php/DSDP/TM/Committer_Phone_Meeting_29-Mar-2007, we can do the following. All these idease are in line with and logical extensions to the current proposal (keep the extension point and use a hidden preference for selecting the default persistence provider): * persistenceProvider extension point allows users to register any number of persistence providers. * There is always a 1:1 mapping between a profile and a persistence provider. In other words, each profile is uniquely associated with a persistence scheme. * On startup, RSE asks each persistence provider in turn to restore the profile kinds that it knows about from disk. Persistence Providers can search any place that only they know in order to restore profiles. This may include files with a particular name in the projects, for instance; so in the future, we can associate a profile with a project easily, just by adding a new RSEProjectPersistenceProvider. * A restored profile keeps the association with the persistence provider that created it, so when saving a profile it saves to the persistent form that it came from. * Through the UI, users can change the persistence provider for a profile. This is equivalent to setting a launch configuration "shared" in Eclipse Platform, but more versatile since more persistence schemes can exist. * For this user-selection of persistence providers, Eclipse Capabilities (aka Activities) can be used to "hide" persistence providers that should not be shown. But successfully restoring a Profile through provider X automatically activates the Capability associated with X. * RSE knows the builtin default profiles "local default" and "Team". If, after restoring profiles from disk, these profiles do not yet exist, they are created. An invisible preference setting (plugin_customization.ini) specifies which persistence provider is used for these default profiles. (This is, basically, the current proposal). * Persistence providers can also be registered as "migrators" for any other Persistence Provider. If provider X.nwe is a migrator for provider with id X.old, then after X.old has read its profile from disk, the provider-id inside the profile is automatically changed from X.old to X.new. Because of this, any future save operation on the profile will write through X.new (the migrated version) while X.old (the original version) remains unchanged. Providers which are migrators are always restored before providers which are not migrators. If during restoring a profile, that profile already exists in memory, it is not changed (so the alrady-migrated profile is not migrated again). * In order to avoid unnecessary plugin activation, the persistenceProviders extension point should also contain some markup specifying the file patterns that it can read. For instance: files="${proj:RemoteSystemsConnections}/dom.properties" files="${resource:*.rseprofile}" files="${metadata}/.plugins/myplugin/*.rseprofile" This slot is optional. If not given, the persistenceProvider will always be activated in order to programmatically find files to restore. * IPersistenceProvider should also get a new callback method "onStartupDone()" that is called after all persistence providers are done importing profiles at startup. This allows to automatically create additional connections like the "Local" system type, but only once all providers have been restored. * In the future, an optional "Export" action can also be defined in order to select any given persistence provider for storing a profile for data exchange. When this is done, a new optional extension point slot "export:boolean" can be added, such that only providers marked as being capable of export are shown in the export wizard. Same for "Import". I think that none of these proposals are necessarily API changes. The only capability we need, is that an RSE Profile must be able to hold a string identifying the persistence provider that created it.
Dave I think we can set this fixed with your addition of an invisible Preference as discussed. For further improvements along the lines of comment #5, I have added some of these to the plan item on bug 170932. Let's use the plan item or a new bug for following up on these. API Docs: With TM 2.0M6, extenders will be able to specify the default persistence provider to use by adding a line like the following in plugin_customization.ini: org.eclipse.rse.core/DEFAULT_PERSISTENCE_PROVIDER=com.acme.PersistenceProvider
(In reply to comment #6) > Dave I think we can set this fixed with your addition of an invisible > Preference as discussed. For further improvements along the lines of comment > #5, I have added some of these to the plan item on bug 170932. > > Let's use the plan item or a new bug for following up on these. > > API Docs: With TM 2.0M6, extenders will be able to specify the default > persistence provider to use by adding a line like the following in > plugin_customization.ini: > > org.eclipse.rse.core/DEFAULT_PERSISTENCE_PROVIDER=com.acme.PersistenceProvider > I've made the change to the preference name to match the one above. This name is now part of the API.
[target cleanup] 2.0 M6 was the original target milestone for this bug
