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 <mailto: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 > <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 > <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 <mailto:platform-dev@eclipse.org> > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/platform-dev > <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
