tree f2113dae7913197af22f48cf7b0335f6d517c7eb
parent 1a4ab470c13de122258d0a55ce7934c44e9f9673
author Alex Blewitt <alex.blewitt@gmail.com> 1593699154 +0100
committer Alex Blewitt <alex.blewitt@gmail.com> 1594072334 +0100

Bug 564876 - Publication of IResourceChangeListener

At the moment, many plugins register their interest in Workspace updates
by calling something that looks similar to:
`ResourcesPlugin.getDefault().getWorkspace().addResourceChangeListener()`

This requires that the workspace is open, and has a static reference to
the `ResourcesPlugin` implementation class (or similar; sometimes they
are wrapped in other `BundleActivtor`s such as `PDEPlugin` or
`SearchPlugin`), which is an Activator-based start-up. As a result, the
plugin has to explicitly depend upon the workspace being up and running
before it can add itself to the list, and manage deregistering
afterwards.

Instead, if we set up a listener in the resources plugin for services
publishing IResourceChangeListener instances, and wiring them up to the
workspace, we can listen out for when the workspace is published and
then subscribe to all the listeners as they come and go.

We can use DS or ServiceTracker to manage this implementation, but
whichever we use, it will handle the registration upon bundle start and
remove the registration from bundle stop.

End user plugins need only provide a simple registration (either through
DS or through an explicit registration in an `BundleActivator`) to be
able to receive subsequent events.  We then also pick up the lifetime of
the `IWorkspace` and will automatically be de-registered if either
service goes away.

There are over 100 entries in the Eclipse platform alone that look like
<resource>.getWorkspace().addResourceChangeListener() which could all be
simplified to use publications of services instead, and that's not
including the 100+ more in tests and example code.

Change-Id: Ib384939b84aa648b1d112365461ac80b7b526353
Signed-off-by: Alex Blewitt <alex.blewitt@gmail.com>