Community
Participate
Working Groups
(Theme: Facilitated On-Boarding) Improve the default Persistence Provider - Associate connections, profiles, filter pools etc. with projects - Store as normal XML files in the workspace, get rid of the RemoteSystemsConnections project (just like Launch Configs!) * This would potentially mean a radical change how filters, filter references and filter pools are handled; but seems to be more aligned with typical use cases, and be more usable * If we cannot get this to work, a workaround could be import / export wizards for connections and filters that write to / read from XML files in the workspace - Use fewer files for storage (improved performance, easier handling for checkin/checkout of team-shared data) - e.g. collapsing Property files by putting the current "directory" path into the Properties Key - Need to investigate more: want a specification for 2.0 even if we cannot implement it immediately (MartinO + DaveD) - Important to understand the long-term idea for user actions etc.
This item will probably not be completely satisfied in R2.0. I'm concerned about moveing profiles into projects. Profiles contain external references that can be broken by this. In addition, there needs to be a way of recognizing profiles when they exist in an arbitrary location and a means of triggering the processing of those profiles when they change. It is not clear to me how this happens yet. Import/export is probably desirable in any case and may be doable in 2.0. I am investigating how user actions play into this now. For 2.0, I think we will need to have this specified and a direction in place for the long term persistence design and migration to it. Design notes should be attached to this defect.
Some good ideas for improving persistence providers are describe in bug 179184 comment 5. The basic ideas are that * There can be multiple Persistence Providers * There is a 1:1 mapping between Profile and Persistence Provider - the granularity is "Profile" - the RSE Team view (rename to Profiles View?) can be used for managing these * Persistence Providers can be used for migrating old storage to new one * A special persistence provider can associate a profile with a project * Persistence Providers can also do one-time import/export outside a workspace.
The other important improvements beyond plain bug fixes are - clarify threading model (bug 177329), and - support transactions for bulk change and explicit commit (bug 163592) - better recovering when persistence files are not available (bug 172437)
The following breaking API changes are being made to the persistence manager interface to have it work entirely with profiles as the unit of persistence. This results in several changes with the major ones being in the persistence manager and minor ones being made in the model object hierarchy and the filter pool and filter pool reference framework. The latter are needed since the persistence manager manages the restoration of filter pool references (particularly forward references). This cleans up the interface considerably while extending the function by allowing multiple persistence providers and for migration between persistent forms. Since this is a breaking change. I need to post this and request comments prior to committing these changes. I will be attaching a patch of the complete change set for review. org.eclipse.rse.core.persistence.IRSEPersistenceManager removed commit(SystemFilterPoolManager) removed commit(ISystemHostPool) removed commit(ISystemProfile) RENAMED removed commit(ISystemProfileManager) added commitProfile(ISystemProfile) RENAMED FROM added commitProfiles() removed deleteProfile(profileName) REPLACED added deleteProfile(persistenceProvider, profileName) REPLACEMENT added getPersistenceProvider(providerId) added getPersistenceProviderIds() added migrateProfile(profile, newPersistenceProvider) registerPersistenceProvider() RENAMED FROM removed registerRSEPersistenceProvider() RENAMED removed restore(ISystemFilterPool) removed restore(ISystemHostPool) removed restore(ISystemProfileManager) removed restoreFilterPool(String) removed restoreFilterPoolManager(...) added restoreProfile(persistenceProvider, profileName) added restoreProfiles() to restore all profiles org.eclipse.rse.core.SystemResourceManager removed getProfileFolder. This has been obsolete for some time. Profile folders are now the province of the persistence providers and have no meaning. org.eclipse.rse.core.filters.ISystemFilterPool removed the instance method createSystemFilterPool(String, boolean, boolean boolean). It bad practice to have an instance method as a factory method for the same class unless one is creating immutable objects based on a previous instance. This were only two uses in the base platform and these have been removed. org.eclipse.rse.core.filters.ISystemFilterPoolReferenceManager changed addReferenceToSystemFilterPool to take only a string argument. The filter pool manger argument is redundant in that the reference string contains a means of resolving it. org.eclipse.rse.core.filters.SystemFilterPoolManager removed setNameGen - redundant method a leftover artifact from the generated code days. org.eclipse.rse.core.model.IPersistableContainer removed beginRestore() and endRestore() - no longer needed because of changes in the persistence manager. org.eclipse.rse.core.model.ISystemProfileManager added addSystemProfile() for use by the persistence manager added getSize() that returns the number of profiles being managed org.eclipse.rse.core.model.ISystemRegistry removed getSystemFilterPool() - it was manufacturing a fake system filter pool so that an instance method could be accessed. bad practice. no longer needed. org.eclipse.rse.core.model.RSEPersistableObject removed beginRestore() and endRestore(). No longer needed by the persistence manager. org.eclipse.rse.core.subsystems.AbstractDelegatingConnectorService removed beginRestore() and endRestore(). No longer needed by the persistence manager. org.eclipse.rse.ui.model.SystemRegistry removed getSystemFilterPool - it was manufacturing a fake system filter pool so that an instance method could be accessed. bad practice. no longer needed.
Created attachment 63824 [details] IRSEPersistenceManager changes This is a rather large patch and may not be current for very long. I will attempt to keep it up to date until the comment period is over.
+1 All changes look good to me. I suggest waiting for comments until the next I-build this thursday, then committing it and doing further evaluation then.
Looking at your list, I think that SystemFilterPoolManager should be internal. Created bug 183161 to track making it internal.
As per 2.0 RC1, the work on this plan item is considered complete: * it is possible to contribute multiple persistence providers by extension point. * The default persistence provider is now outside the workspace * Profiles are marked "dirty" in order to support persisting relevant items only * Explicit transaction support has been added to allow for bulk operations * Clients can know when persistence operations are ongoing or complete. For details, see the "dependent" bug entries.
fixed per 2.0RC1. Follow-up work is tracked in bug #175306 (adding documentation), bug #189858 (avoid generating the RemoteSystemsConnections project) bug #181939 (avoid persisting items that have never been active)
[target cleanup] 2.0 RC1 was the original target milestone for this bug
