Going plugin (from an OSGi bundle)

The Eclipse plugin creation wizard allows to create OSGi bundles or Eclipse plugins.

The most notable difference is that the PDE plugin editor does not show the extension tab.

I recently wanted to use an plugin extension in a project which I initially created based on OSGi; therefore I wanted to enable the “Extension” and the “Extension Point” tab in the PDE editor.

To do this remove the line “pluginProject.extensions.false” from the file .settings/org.eclipse.pde.core.prefs. Re-open the “MANIFEST.MF” and the Extensions tab will show.

Many thanks to Neil Bartlett for sharing this tip via twitter.

About Lars Vogel

Lars Vogel is the founder and CEO of the vogella GmbH and works as Eclipse and Android consultant, trainer and book author. He is a regular speaker at international conferences, He is the primary author of vogella.com. With more than one million visitors per month this website is one of the central sources for Java, Eclipse and Android programming information.
This entry was posted in Eclipse, OSGi and tagged , . Bookmark the permalink.

16 Responses to Going plugin (from an OSGi bundle)

  1. In reality, an OSGi bundle is an Eclipse plug-in and vice versa.

    We shouldn’t perpetuate the myth otherwise.

    If you want to enable the extensions, you can go to the Overview page and click “Extensions” and that will always make the tab appear.

  2. Lars Vogel says:

    @Chris Doesn’t have a plugin provide additional functionality, e.g. as the extension mechanism which is not available in OSGi?

    I always assume “OSGi bundle <= Plugin"

    Thanks for the tip with the click on "Extensions" that is easier then modifying the preferences directly.

  3. Neil Bartlett says:

    I agree with Chris, there is no difference. We don’t have a special name for bundles that use Declarative Services, or Spring-DM or any other extender model, so we don’t need a special name for bundles that happen to use the extension registry.

    I didn’t know about the ability to click on the Extensions link in the overview; that does seem nicer than editing the preferences directly. Nice tip Chris!

  4. Lars Vogel says:

    @Neil thanks for your good perspective. DS bundles also have their additional stuff and still they are considered special. That helps me to understand the statement “bundles == plugins”.

  5. The extension registry is simply a layer on top of OSGi, similar to DS. The extension registry can run on other OSGi frameworks if need be. And as Neil mentioned, we don’t use special names for other bundles using the extender model… the plug-in name is simply a legacy of Eclipse.

    We have to live with it for awhile. I’m planning to change the Eclipse wizards a bit in Eclipse 3.7 when we start merging some of the SpringSource tooling into PDE.

  6. Wim Jongman says:

    Every plug-in is a bundle but not every bundle is a plug-in as in every sparrow is a bird but not every bird is a sparrow.

    Saying plug-in indicates that the bundle specifically extends the Eclipse platform. I don’t see why we need to say that every bundle is a plug-in if it does not extend the Eclipse platform.

    A plug-in developer knows how to extend the eclipse platform and use OSGi. A bundle developer knows how to use OSGi.

    The term just exists so it will aways be confusing to new ppl. The difficult part is to understand why they are the same. Once you understand that, the naming becomes irrelevant.


  7. Ian Bull says:


    If I produce a bundle that provides a service (call the service an Ian’s Extension), and you provide a bundle that uses my service (you require my bundle to be present, and you provide an ian.xml to configure it), is your bundle really a bundle? Of course it is.

    That’s the exact same thing that happens in your case. Eclipse provides a service (called the extension registry) and some *bundles* choose to use that service (they provide a plugin.xml to configure it). They are bundles. They require the extension registry bundle to be present, but it doesn’t make they more or less of a bundle.

  8. Lars Vogel says:

    @Chris you are making a good point. The plugin wizard has two distinct option, run on equinox and run on OSGi. This does not send the message across that it is the same thing.

  9. Wim Jongman says:

    @Ian Yes, I understand and agree. Every plug-in is a bundle like every sparrow is a bird. I just think that nowadays the term plug-in has evolved to indicate it is a bundle that is specifically used to extend eclipse.

    Here is the difference between bundles and plugins:

    Two developers meet at JAX. Says the one to the other: “Hi, do you know OSGi?” Says the other: “Well, sure! I have been developing plug-ins since 2007”. Then the first THINKS: “Aah, that guy has been around and uses Eclipse. He has been using OSGi to extend the Eclipse platform and knows all about views and adapter factories and all that kind of stuff”. And in total understanding they open their respective laptops and float back into their comfort zone.

    Two developers meet at JAX. Says the one to the other: “Hi, do you know OSGi?” Says the other: “Well, sure! I have been developing bundles since 2007”. Then the first ASKS: “nice, did you ever try to use Eclipse as a framework?” The second guy says: “Nah, I we only use it for development”. And in total understanding they open their respective laptops and float back into their comfort zone.

  10. Ian Bull says:

    @Wim, As yes, the perception issue. This is the thing (I think) zx is trying to change.

    I would rather re-think the term “plug-in” to mean some add-on to Eclipse. A plug-in can be made up of one or more bundles, and possibly more or more features. In this view, mylyn is a plugin. Of course, mylyn is made up of several OSGi bundles and several features… but the concept of “plug-in” is changed to mean the add on to eclipse.

    I don’t think others share my view on this though 😉

  11. Dann Martens says:

    I subscribe to the viewpoint of Wim Jongman.

    I have found the distinction between the words ‘bundle’ and ‘plug-in’ useful and still use it and explain it along those lines. This position also fits the historical reality of those naming concepts. Every plug-in is a bundle, but a plug-in contributes to the Eclipse layer on top of the OSGi layer.

    @Ian: please don’t try to do that, that’s making things even worse, adding to the confusion. If Mylyn cannot be considered to match the concept of a *single* Eclipse Feature, perhaps a new word should be coined to designate that type of construct.

  12. Ian Bull says:

    I do understand where you are coming from. I had the same view point for years (Chris just bought be enough beer one night and managed to convince me otherwise 😉 ).

    The problem with designating things “plug-ins” if they contribute to the Eclipse layer, is you have to define the Eclipse Layer. Not all “modules (using a different word)” that ship in the plugins directory have a plugin.xml. If you don’t have a plugin.xml are you a plugin? Some just use SWT, are these plugins? Some get registered and consumed via OSGi services, are these plugins? At what point are you designated a “plug-in”?

  13. Dann Martens says:

    @Ian Of course, that’s an interesting point, which makes this exchange of interpretations rewarding.

    (On the side: From a deployment perspective, everything is a bundle. Because the ‘plugins’ folder has a history tied to the original Eclipse modularity system, the name of that folder is confusing. And perhaps a candidate for a change request.

    Historically, the adoption of OSGi has introduced a level of blurring which makes this discussion fairly complicated. The adoption introduced an overlap in functionality, as there are now different programming patterns available to ‘contribute’ or to ‘extend’. As it stands today, the framework taps into those different layers at the same time, creating a mix which lies at the heart of this discussion, I think.

    Categorizing bundles, for example as a higher-level type such as a ‘plug-in’, has become debatable because a bundle can contain a mix of fingerprint meta-data: OSGi declarative services, plugin.xml Eclipse extensions, … .

    Still, I find that sentences like ‘mixing bundles and plug-ins’ are still valid given the specific nature of the layers in the framework. Apart from meta-data content in the bundle, there are also life-cycle aspects to consider. I do consider the framework to have become a mix of both: bundles en plug-ins.

    There is enough to distinguish, enough to warrant that both names remain in existence. Unfortunately, as they are ‘related’, making the distinction in some cases is like separating Siamese twins, in which case only some convention helps to make the call. But because sometimes the distinction is clear-cut, I can’t help feeling that we will never be able to use a single blanket term.

  14. Ken Gilmer says:

    Nice discussion! The term “plugin” is used in Equinox as well, it’s not just Eclipse as an application. Personally, I wish Equinox would call them bundles…

    Can anyone tell me the extension point in the wizard Lars’s first screen shot? How can I add something besides “Equinox” to the wizard? Or, if there is no extension point, what’s the purpose of the drop down?

  15. jtonic says:

    >> To do this remove the line “pluginProject.extensions.false” from the file .settings/org.eclipse.pde.core.prefs.

    or use the Project Properties > Plug-in Development > Always Show the Extensions and Extension Points tab.

    Nice talk about the 2 concepts bundles and plugins. I agree with Ian but I can tell you most of Eclipse plugin/OSGi starters are pretty confused about the 2 notions.

Comments are closed.