Community
Participate
Working Groups
There are two org.eclipse.rse.core packages - one in UI plugin and one in the core plugin. This is confusing at least. I propose renaming the UI one to org.eclipse.rse.ui.systems.
I think I disagree. IMHO, all the contents of org.eclipse.rse.core in the UI plugin should be refactored in order to get rid of any references requiring UI and moved into the core plugin. It shouldn't be that bad -- after all it's mostly SubSystem, events, and some other classes that should be available from headless (without UI) anyways.
Yes, you are probably correct. In any case org.eclipse.rse.core disappears from the UI plugin. There may be some implementation remnants or extensions that will have to find homes as a result of the refactoring and those may, perhaps, live in a org.eclipse.rse.ui.systems package. This bears further looking at. But I agree that a blanket rename is probably too coarse.
... especially since in terms of migration, if a class just moves from (UI)org.eclipse.rse.core to (Core)org.eclipse.rse.core there is no change in user code needed whatsoever. If you rename the package, user code needs to organize imports at least.
Changed name of report to more closely match the function. The old name was: [api] rename org.eclipse.rse.core package of the UI plugin
Stage 1 - Moving the following classes pretty much verbatim: IRemoteSystemsProject, RemoteSystemsProject, RemoteSystemsTempProjectNature. - [api] Moving the following classes to other packages: ISystemViewSupplier from org.eclipse.rse.core to org.eclipse.rse.ui - none-structural modifications SystemResourceListener - some comment changes ISystemPreferencesConstants - formatted and recommented in preparation for moving core preferences to the core plugin. The following preferences will be moved: /* * core preference keys */ public static final String SYSTEMTYPE = ROOT + "systemtype"; //$NON-NLS-1$ public static final String SYSTEMTYPE_VALUES = ROOT + "systemtype.info"; //$NON-NLS-1$ public static final String USERIDPERKEY = ROOT + "useridperkey"; //$NON-NLS-1$ public static final String USERIDKEYS = ROOT + "userid.keys"; //$NON-NLS-1$ public static final String ACTIVEUSERPROFILES = ROOT + "activeuserprofiles"; //$NON-NLS-1$ public static final String USE_DEFERRED_QUERIES = ROOT + "useDeferredQueries"; //$NON-NLS-1$ public static final String RESTORE_STATE_FROM_CACHE = ROOT + "restoreStateFromCache"; //$NON-NLS-1$
Stage 2 Remove the following classes completely. These were development time utility classes or could be easily replaced by java platform classes. - SystemElapsedTimer - SystemSorter - SystemStringTokenizer Move the following class to org.eclipse.rse.ui.view SystemPerspectiveHelpers Getting rid of SystemElapsedTimer will remove some code from SystemView and alter several protected method definitions. However, SystemView will be made internal and so protected method defintions will no longer be API.
Talking about SystemPerspectiveHelpers going to UI: I think the following methods should be removed from ISystemRegistry, and either be moved into ISystemRegistryUI or a completely separate class / interface: public void showRSEPerspective(); public void expandHost(IHost conn); public void expandSubSystem(ISubSystem subsystem);
Stage 3 integration Moved the following to core from ui PasswordPersistenceManager SystemResourceConstants Made the following utility class in Core from methods found on RSEUIPlugin RSEHostUtil Moving PasswordPersistenceManager required that preferences that were in the UI plugin are moved to Core. SystemPreferencesManager was rewritten to manage both Core and UI plugin preferences. It involved refactoring of several UI classes that were managing their preferences independently of SystemsPreferenceManager. All of these now use SystemsPreferencesManager or will soon. In addition, SystemsPreferencesManager will be split into core and ui pieces in the next stage. This integration also affects the user defined actions contribution. The attachment for that contribution will be refreshed soon. A SystemsPreferencesManager test suite has been started and is included in the combined test suite.
Can you move ISystemFilePreferencesConstants.SHOWHIDDEN into the new, Core-level SystemPreferencesManager as well? This constant is used by almost every files subsystem but it's currently in an "internal" package so it should be made API one way or the other.
Stage 4 - Created a new RSEPreferencesManager for handling preferences for the core plugin. - Added code to migrate preference values from the UI to the Core plugin preference stores - Removed unused globals from IRSEPreferencesNames - Created the RSEPreferencesInitializer to follow new eclipse preferences initialization scheme for non-UI plugins - Created PreferencesMapper in the UI plugin for wrapping the org.eclipse.runtime preference stores as org.eclipse.jface preference stores to that they can be used in FieldEditors - Moved SystemPreferencesManager from the org.eclipse.rse.core package to the org.eclipse.rse.ui package since all the preferences that are managed are now UI preferences. - updated SystemTypeFieldEditor and RemoteSystemsPreferencePage to use the new preferences locations for core preferences. - propagated the change for moving SystemPreferencesManager to several classes.
(In reply to comment #9) > Can you move ISystemFilePreferencesConstants.SHOWHIDDEN into the new, > Core-level SystemPreferencesManager as well? > > This constant is used by almost every files subsystem but it's currently in an > "internal" package so it should be made API one way or the other. > I don't think this should be moved to core. Rather, it should be moved to some common file plugin that depends on the ui. It is a UI preference and a file preference, not a core preference value.
(In reply to comment #11) The SHOWHIDDEN preference is currently used by every file subsystem contributor in the part that's meant to be non-UI. So either this usage is incorrect or the Preference must go into a non-UI public API. I have filed bug 174767 to track this issue separately.
[168870][api][refactor] Preparation for moving SubSystemConfigurationProxy from ui to core. - add "getAllSystemFilterPoolManagers" to ISubSystemConfiguration, was in SubSystemConfiguration - change ISubSystemConfigurationProxy to not return ImageDescriptors but rather URLs that locate the images - created a SubSystemConfigurationProxyAdapter (and factory) to adapt SubSystemConfigurationProxy for getting images - changed code using SubSystemConfigurationProxy's image calls to use the adapter - other non API changes
[168870][refactor] Moving SubSystemConfigurationProxy and SubSystemConfigurationProxyComparator from UI to Core. No API changes since these are internal classes.
Will accomplish a bit more for M7.
Reassigning as discussed on http://wiki.eclipse.org/index.php/DSDP/TM/Committer_Phone_Meeting_15-May-2007 Will move remaining classes to org.eclipse.rse.ui in order to get rid of the split package
Work completed. Moved SystemAdapterHelpers -> org.eclipse.rse.ui.view SystemBasePlugin --> org.eclipse.rse.ui SystemResourceListener --> org.eclipse.rse.internal.ui SystemRemoteObjectMatcher --> org.eclipse.rse.core of the core plugin (no API change) Added interface ISystemRemoteObjectMatchProvider between IRemoteObjectIdentifier and ISystemRemoteElementAdapter in order to support SystemRemoteObjectMatcher in non-UI (no API change) Changed method signatures -- Replaced first paramter "Shell" by last paramter "IProgressMonitor" in order to be consistent with similar long-running operations and allow pushing these methods into non-UI: ISystemRemoteElementAdapter.getRemoteParent(Object, IProgressMonitor) ISystemRemoteElementAdapter.getRemoteParentNamesInUse(Object, IProgressMonitor) Migration Docs -------------- 1. Organize Imports 2. If you implement ISystemRemoteElementAdapter, change the method signatures of getRemoteParent() and getRemoteParentNamesInUse() as mentioned.
Actually, looking at the whole (long) history of changes done for this bug, more migration docs will be needed.
[target cleanup] 2.0 M7 was the original target milestone for this bug
