Neil, > > The extension point mechanism Eclipse uses is NOT based on OSGi > > It IS based on OSGi. It is an example of the extender pattern which is > common in OSGi. But it is not based on Services.
Could you please elaborate a bit how it is based on OSGi? I mean I understand that Eclipse is based on OSGi itself and the plugins are OSGi bundles, I mean how Eclipse extension points mechanism is based on OSGi? If you have some link that would be great! > > If I want to use say declarative services (or simply services) as > extension > > points mechanism it seems I have only one key: service interface, that is > > when I declare my service I just announce to the framework that I have a > > service, I don't specify which extension point this service is intended > to > > extend. > > Correct, this an advantage of services -- they do not need advance > knowledge of which bundles will consume them. It's an advantage if you need a service, but extension point is not exactly a service. For example you have an interface Command and there are two different extension points (A and B) which could be extended by those commands. I am creating a plugin to extend A, I don't want to extend B because my commands are for A only. And there is some other plugin which extends B using its own commands. The problem here is that my plugin which extend A and this other plugin which extend B they both use this very convenient interface Command. So they cannot just declare that they provide services Command because A and B will try to consume commands from both of them. Of course I can create unique interfaces for A and B and extend them through those unique interfaces, but in many cases it's artificial. Basically I am forced to create those unique interfaces because interface is the only key here. > > I guess I can add some parameter to the service (i.e. extension point > name) > > and have the framework code filter out services by this parameter when > > requested. It could work, but I don't really like this approach because > > these parameters are somewhat soft constraints and not enforced by OSGi > in > > any way. > > It sounds like you want to ensure that services can only be consumed > by certain bundles, like Eclipse Extensions. Why? because those are not services. they are extensions. a service provides some service and does not know about how it is used. an extension in many cases extends a very specific functionality and very often aware what it extends and how it is used. > Another reason I don't like it is because I suspect that the > > service (extension) will be loaded when a component requesting this > service > > is loaded, but I want it to be loaded only when I specifically requested > > this service. > > If you use Declarative Services then the implementation object for the > service will be loaded lazily, i.e. only when a consumer actually > attempts to use it. Because of this, in my opinion, DS has most of the > advantages of Eclipse's Extensions, and none of the disadvantages (and > the disadvantages of Eclipse Extensions are numerous and significant). What are numerous and significant disadvantages of Eclipse Extensions? I guess I can think of some disadvantages, but I would not call them significant :) Thanks! -- Dmitry Skavish
