Hi Dmitry, Since you ask, here are the top three issues I have with Eclipse Extensions:
1) Bundles offering either extensions or extension points must be singletons, i.e. you can only have one version installed, and there is no support for checking the compatibility of an extension with the API of the extension point by version. 2) Lack of control. Extensions are read from any bundle that has a plugin.xml and is at least RESOLVED. But we have little control over the RESOLVED state, and in particular there is no way to request that a bundle be "unresolved" except by fully uninstalling it. DS on the other hand works with ACTIVE state, which means we have explicit control of the visibility of bundles through activating and deactivating them. 3) Bolted-on dynamics. The Extension Registry APIs were designed before Eclipse used OSGi as its underlying module system, and thus before it was possible to dynamically install and uninstall bundles at runtime. They have since been extended with dynamic capabilities but the extensions are difficult to use, and in practice very few Eclipse plug-in developers pay any attention to dynamics. This is why Eclipse *still* insists that you restart after installing new plug-ins, four years after adopting OSGi. Since DS offers the same laziness benefits as extensions, the one remaining advantage of extensions versus DS is their support for richer and more structured metadata, in the form of an XML tree versus the name/value pairs used with services/DS. Regards, Neil On Thu, Jun 11, 2009 at 11:10 PM, Dmitry Skavish<[email protected]> wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
