- Technically speaking a "plugin" is an installable OSGi plugin, which ends up in the plugins direcory of an eclipse installation (or one of its extension location) and gets loaded when eclipse starts. It can either be a directory or a .jar file. It must contain a MANIFEST.MF and/or a plugin.xml file. Multiple plugins can be assembled into an installable "feature". (Which is also confusing, that a "feature" consists of a set of plugins. As a navive person I would expect a plugin to have multiple features).
- Eclipse users think of "plugins" at a higher level of granularity. If you go to eclipse-plugins.info, there are over 1000 "plugins" to install. But those plugins usually consist of multiple OSGi plugins and installable features...
You often hear: "Oh, if found this new and cool eclipse plugin, you should install it and try it". In this case the speaker rarely means a single OSGi plugin, but an "eclipse extension". If you hear: "My plugin depends on plugin org.foo.bar", we are talking about OSGi plugins.
Therefore it can be very confusing to talk about "plugins". And I think "user plugins" should be called eclipse extensions or add-ins or something that can not be confused with technical plugins.
Any ideas how to resolve this confusion?
This is how I deal with it.
ReplyDeleteAny group or set of plugins, I just call plugin. That is, "I just downloaded the ECF plugin." I know this is totally wrong, but it is fairly ingrained.
Anything that refers to a specific OSGi bundle, I just call bundle.
I think the term extension is a fantastic word to use for a set of plugins.
I think that it's unnecessary to worry about it too much. If I depend on the org.eclipse.core.runtime plugin, I don't actually care that it may happen to depend (and/or include) org.eclipse.equinox.common plugin.
ReplyDeleteSimilarly, when I go to an update site to install a new feature (e.g. vex.sourceforge.net) I don't care terribly that it may be implemented in a single plugin or multiple ones. It may even be the case that when I first install it, it's a single plugin, but that some time afterwards it's refactored into seperate plugins. I specify which one I want; transitive dependencies are handled under the covers.
I think that the bigger problem is people saying 'Eclipse? Oh yeah, it's that Java IDE' when it is in fact a framework, and what they're really referring to is Eclipse JDT. That more than anything else is a stumbling block to Rich Client Applications since shops that don't know about it just think that Eclipse is capable of hosting non-IDE related applications.
I think if all "extensions" were packaged up into a feature, this wouldn't be an issue. Is there a technical reason that you would not use a feature, or is there a use case for creating a group of plugins on their own, not encapsulated within a feature? It allows proper update sites, enabling/disabling, etc.
ReplyDeleteThis is a great point. I am often tripping over what to call the CDT. Most people just say they download and install the "CDT" and don't call it a plugin or feature or anything. Same goes for the other projects. And actually, I use that term "projects" although you don't download a project, the project works on the thing you download. No help from me...
ReplyDeleteThis comment has been removed by a blog administrator.
ReplyDelete