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:

fig2 300x193 Plug in? Bundle? Blugin?

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:

fig1 300x193 Plug in? Bundle? Blugin?

Right?

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.

fig3 300x193 Plug in? Bundle? Blugin?

And now I can’t get that song out of my head icon wink Plug in? Bundle? Blugin?

You may also like...

Share this Post

Twitter0
Google+1
LinkedIn
Facebook

Tags

10 Responses to “Plug-in? Bundle? Blugin?”

  1. 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?

  2. christian campo says:

    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)

  3. Brindy says:

    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.

    Cheers,
    Brindy

    (@arumbrindy)

  4. 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,
    Elias.

  5. Brindy, you’re simply wrong and perpetuate the lie :)

    You can write “plug-ins” in Eclipse that don’t depend on the extension registry… we have plenty within the Eclipse SDK.

    “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”

    That’s no different than someone using DS or Spring DM. Basically anything that uses the extender pattern will depend on some external bundle… whether it’s the extension registry or DS.

  6. Elias, regarding dynamics, sure, you may have a requirement that says you don’t care. It’s a much simpler life if this is the case :)

    In the RCP case, the reason dynamics hasn’t been a big problem is because people got used to restarting after updates (because it was mandatory). Now with p2, this isn’t really the case anymore… we may see people’s attitudes shift in the future.

  7. Brindy says:

    Here’s another (petty) argument. By calling bundles plugins you’re redefining part of the OSGi specification. :P

    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 :D

  8. Alex Blewitt says:

    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 …

  9. Alex, I would love to change the terminology to bundles. It’s actually on my mind for the 3.6 release. However, these would be wide reaching changes… all the documentation uses the term “plug-in” … there’s an ecosystem built up on this term.

    Change is always hard :)

  10. Plundle? ;)

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

10 responses so far

Written by . Published in Categories: Planet Eclipse

Author:
Published:
Apr 29th, 2009