Community
Participate
Working Groups
Currently, org.eclipse.rse.files.ui.Activator is not internal for the only reason of allowing forced plugin activation, e.g. in org.eclipse.rse.internal.subsystems.files.dstore.Activator#start(). But forced plugin activation is not a good idea. And it looks like the only reason for forcing plugin activation, is that the adapter factories need to be registered. This should be done by declaration in plugin.xml instead, through the org.eclipse.core.runtime.adapters extension point. For the same reason, org.eclipse.rse.shells.ui.Activator and org.eclipse.rse.processes.ui.ProcessesPlugin should also be internal, advertising their adapter factories through plugin.xml instead.
I tried to do the following with the files.ui plugin.xml: </extension> <extension point="org.eclipse.core.runtime.adapters"> <factory class="org.eclipse.rse.internal.files.ui.view.SystemViewFileAdapterFactory" adaptableType="org.eclipse.rse.subsystems.files.core.subsystems.IRemoteFile"> <adapter type="org.eclipse.rse.ui.view.ISystemViewElementAdapter"/> </factory> <factory class="org.eclipse.rse.internal.files.ui.view.SystemViewFileAdapterFactory" adaptableType="org.eclipse.rse.subsystems.files.core.subsystems.IRemoteFile"> <adapter type="org.eclipse.ui.views.properties.IPropertySource"/> </factory> <factory class="org.eclipse.rse.internal.files.ui.view.SystemViewFileAdapterFactory" adaptableType="org.eclipse.rse.subsystems.files.core.subsystems.IRemoteFile"> <adapter type="org.eclipse.rse.ui.view.ISystemRemoteElementAdapter"/> </factory> </extension> This allowed me to comment out the code in the Activator that registers the adapters. However, the problem I'm seeing is that if I don't reference the Activator for files.ui in a forced manner from file subsystem plugins (ftp, dstore, ssh, etc), the extension point doesn't seem to take effect. To get around that I added the following extension point: <extension point="org.eclipse.ui.startup"> <startup class="org.eclipse.rse.internal.files.ui.Activator"/> </extension> I'm not sure if this is the best way to deal with this. Is another way to make sure adapter contributions are made active?
Sorry, this was my fault. From the ISV Docs of IAdapterManager: http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/eclipse/core/runtime/IAdapterManager.html "Factories registered with this extension point will not be able to provide adapters until their corresponding plugin has been activated." The right solution is to register adapter factories in plugin.xml, and force plugin activation through IAdapterManager#loadAdapter(). For files, this forced activation can be done in org.eclipse.rse.files.core.Activator because it uses the indirect method instead of the direct one. This also has the advantage that the dependency from org.eclipse.rse.subsystems.files.ssh (and others) to org.eclipse.rse.files.ui is no longer necessary, which will allow us to move the subsystems into non-UI for headless applications in the future. Checking this in now for files. It is an API change since the "fastpath" access methods in org.eclipse.rse.files.ui.Activator are removed: getSystemViewFileAdapterFactory() getSystemViewSearchResultSetAdapterFactory() getSystemViewSearchResultAdapterFactory() Change set: [180519] declaratively register rse.files.ui. adapter factories
Doing the same for shells and processes, removing these methods: Activator#getSystemViewOutputAdapterFactory() *Factory#registerWithManager(IAdapterManager) Change sets: [180519][api] declaratively register rse.shells.ui adapter factories [180519][api] declaratively register rse.processes.ui adapter factories [180519][api] declaratively register adapter factories [180519][api] moving Activators to "internal" Migration guide for extenders: * If your code has been using Activator.getDefault() to force plugin activation only, this is no longer necessary. Simply remove the code. * You may also get rid of references to files.ui in Manifest.mf * Explicit access to adaptor factories also needs to be removed. Use the default Platform.getAdapterManager().getAdapter() instead. * Other access to the Activator (e.g. to get resource strings or images is deprecated. Copy the strings or images to your own plugin, or file a bug for requesting public API access to such strings and images.
[target cleanup] 2.0 M6 was the original target milestone for this bug
