Hi everyone,
I’ve proposed a change at
https://git.eclipse.org/r/c/platform/eclipse.platform.resources/+/165750
<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@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
