[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [platform-dev] Creating a whiteboard pattern for IResourceChangeListener
|
Hi Alex,
Maybe I'm totally wrong but I think I remember that early initialization
of Resources-Plugin via by DS stuff caused problems in the past because
the workspace-selection dialog did not come up any more (something you
don't spot when running with an inner-eclipse).
Maybe I'm totally wrong and as it's been a looong time since I hacked
the Eclipse Platform so if what say is BS just ignore it ;-)
Tom
Am 02.07.20 um 17:58 schrieb Alex Blewitt:
Hi everyone,
I’ve proposed a change at
https://git.eclipse.org/r/c/platform/eclipse.platform.resources/+/165750 to
provide a way of registering IResourceChangeListener instances via an
OSGi service rather than an explicit call to IWorkspace.
There’s lots of calls in projects that look something like:
ResourcesPlugin.getWorkspace().addResourceChangeListener(resourceChangeListener);
This has an ordering dependency that the workspace needs to be running
before this registration occurs. Of course, if the workspace doesn’t
exist at this point we aren’t going to be receiving any events but we’d
like to be able to start them in either order.
If we use the OSGi whiteboard pattern, we can turn it on its head and do:
context.registerService(resourceChangeListener,
IResourceChangeListener.class);
(We do something similar in many places for DebugOptions.)
Now we have decoupled the start order dependency, and with the change
above we’ll now pick up the binding when the resources plugin is
available, and will automatically deregister when either service goes away.
We can also use this to register the listeners via DS:
<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.4.0" immediate="true" name="ExampleResourceListener">
<implementation class="org.example.ExampleResourceListener"/>
<service>
<provide interface="org.eclipse.core.resources.IResourceChangeListener"/>
</service>
<!-- 1 == IResourceChangeEvent.POST_CHANGE -->
<property name="event.mask" type="Integer" value="1"/>
</scr:component>
The additional properties on the service will allow a subset of the
event types to be passed in (in this case, 1 == POST_BUILD). There is a
minor disadvantage in that this is an integer rather than a compile-time
constant reference, though if the registration in code is used you can
have a Dictionary including IResourceChangeEvent.POST_BUILD as the key
in the dictionary.
This approach of having a whiteboard pattern (either DS or
ServiceTracker) for listeners could be replayed on other listener types
as well; but from what I can tell, the IResourceChangeListener is the
most popular in hooking together the world.
Arguably it might be more ‘OSGi’ to attempt migrating the
IResourceChangeEvent to an OSGi EventAdmin topic, but that would require
more invasive dependency and code changes than exists at the moment.
Having everything in DS means that we can start the components lazily
and avoid the use of Activators, which will certainly help with the
start-up times.
Thoughts?
Alex
_______________________________________________
platform-dev mailing list
platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev