Plug-in? Bundle? Blugin?

Plug-in? Bundle? Blugin?

Elias recently blogged about about the ‘OSGi for Eclipse Developers‘ presentation I gave. There’s been some commentary about Eclipse plug-ins not being OSGi bundles. It was mostly spurred by this slide:


What we were trying to convey with this picture is that the OSGi and Eclipse communities tend to argue over a name. In the end, it’s still the same thing. Let me repeat, an Eclipse plug-in is an OSGi bundle and vice-versa. If anyone tells you otherwise, they are lying. There are people that like to claim that since Eclipse folks tend to heavily use the Extension Registry (i.e., plugin.xml) that they aren’t a bundle. The Extension Registry is simply another OSGi service and really just a feature built on top of the wonderful OSGi service registry. The Extension Registry also runs on other OSGi frameworks like Felix (it can even run outside of OSGi if you want). It’s no different than the Declarative Services (DS) bundles or Spring DM bundles (well I guess DS is in the OSGi specification). The only issue that you have to watch out for when developing a bundle is being tied to a framework. In Eclipse land, we have some special manifest headers (e.g., Eclipse-BuddyPolicy) that may not work in other frameworks. This isn’t really an Eclipse specific issue, other frameworks suffer from the same fate if they invent manifest headers. It’s still an OSGi bundle in the end.

What have people experienced out in the field regarding this debate? Anything? Any ideas on how to make things better?

In the end, what we were trying to say that the communities need to stop bickering and focus on the goal of getting more people on OSGi:



On a somewhat related note, the more important message in that presentation was that services are dynamic and you need to get in your head. I know programming for dynamics is hard but you just need to remember that terrible Culuture Club song when you think of OSGi services… you come and go!Β Anticipate dynamics and use things like Declarative Services to make your life easier.


And now I can’t get that song out of my head πŸ˜‰

  • christian campo
    Posted at 22:13, 2009-04-29

    I think “the point” at least my point was that if they are the same (and I agree that bundle and plugin are the same) then we should give up one of the two names.

    Since I feel that bundle is the better name, Eclipse should turn over and also call it bundle. That would create no harm (just some transition) and then life gets easier. (you dont need to talk about plugin vs bundle again how is that for an improvement)

    +1 bundle πŸ™‚ (maybe it helps to repeat that in every comment I make)

  • Posted at 22:27, 2009-04-29

    A plugin is a bundle, but a bundle is not a plugin. It’s simply a fact, and you can’t change that fact by telling people that it is a lie. πŸ™‚

    Of course, at the lowest level the only reason a plugin is different is because it depends on the plugin registry, which is no big deal, but they *are* different.

    There’s also a difference in paradigms. Plugins encourage extensions and extension points, where as bundles encourage services. Of course you can do services in a plugin, but you can’t do extensions and extension points in a bundle … unless you have a dependency on the plugin registry.

    You also imply that plugins are somehow like declarative services, but like I just said, it’s a different paradigm.

    That all said, I do tend to explain OSGi to people who have never heard of it with a high level dissection of Eclipse, something like this:

    “Eclipse is a bunch of plugins. Plugins are OSGi bundles. Eclipse runs on Equinox which is an OSGi container and implementation of the OSGi specification. Bundles are a container of code that can run in an OSGi container. Eclipse plugins have a dependency on the plugin registry, which is cool because it works with other containers as well.”

    Something like that anyway.

    Just my thoughts.



  • Posted at 22:27, 2009-04-29

    Hi Chris,

    with regard to dynamicity, I beg to differ a little.

    It always depends on the goals / requirements. If there is no concrete user-requirement for dynamicity I would be hesitant to support it, since the added cost/complexity would not result in a payoff. For example many RCP apps I’ve worked on, having to restart the app after install/update was not an issue. In those cases I’m sure that it would not make sense to spend more $/effort to make the app dynamic.

    For servers or long-running apps this may be totally different of course.

    My two cents,

  • Posted at 22:52, 2009-04-29

    Here’s another (petty) argument. By calling bundles plugins you’re redefining part of the OSGi specification. πŸ˜›

    But OK, OK I’m coming around to your way of thinking. So like christian campo says, perhaps it’s about time that Eclipse dropped the name plugin rather than trying to get everyone calling bundles plugins?

    +1 bundle πŸ˜€

  • Neil Bartlett
    Posted at 22:11, 2009-04-29

    I haven’t heard anybody claiming that Eclipse plug-ins aren’t bundles because they use extensions rather than services, but I have heard the idea that a plug-in is somehow an Equinox-specific extension to the spec.

    I wonder if allowing different names for plugin.xml would help to break this meme? Maybe a manifest header pointing to one or more XML files inside the bundle?

  • Alex Blewitt
    Posted at 08:42, 2009-04-30

    Why not look at changing terminology in Eclipse to call them ‘bundles’ instead? Plug-in development environment, plug-in registry, plug-in view … simply change all of these to ‘Bundle’ in 3.6 and be done with it …

  • Posted at 17:30, 2009-04-30

    Plundle? πŸ˜‰

    +1 for less worrying about naming and more focus on helping devs write modular apps (without getting in their way)