Hi Alex, Sounds great to me. Thanks for working on this.
Let's continue this discussion via a bug report. Best regards Alex Blewitt <alex.blew...@gmail.com> schrieb am Do., 2. Juli 2020, 17:58: > 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@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/platform-dev >
_______________________________________________ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
