No worries. Thanks for thinking outside the box. Alex Blewitt <alex.blew...@gmail.com> schrieb am Do., 2. Juli 2020, 18:51:
> Sorry, should perhaps have filed that first. > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=564876 > > On 2 Jul 2020, at 17:21, Lars Vogel <lars.vo...@vogella.com> wrote: > > 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 > > > _______________________________________________ > 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
