Bugzilla – Full Text Bug Listing
| Summary: | Provide terminology friendly to OSGi bundles developers | ||
|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Philippe Ombredanne <pombredanne> |
| Component: | UI | Assignee: | PDE-UI-Inbox <pde-ui-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | b.muskalla, baumanbr, caniszczyk, contact, curtis.windatt.public, d.nachev, darin.eclipse, deboer, d_a_carver, ed.burnette, ekke, francois, gunnar, ian.skerrett, irbull, jeffmcaffer, john.arthorne, kowalskilee, patrick, sja.eclipse, slewis, tjwatson, wassim.melhem, wmitsuda, zina |
| Version: | 3.2 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | stalebug | ||
| Bug Depends on: | 407765 | ||
| Bug Blocks: | |||
|
Description
Philippe Ombredanne
Such fundamental changes sound more like to something to consider for a 4.0 release, rather than a 3.3 release. Moving the discussion to the runtime inbox since all files/terminology referenced here are runtime-related. What if we add to the existing name with something like the Bundle and Plug-in Development Env (BPDE)? I know this violates the unspoken rule of having only three letters in an acronym :) I like the idea of adding Bundle to the name since the current tooling would work great in developing OSGi bundles. I think we could really increase the number of users if we publicize that we are a great bundle development environment also. it is not clear this is really worth it. I am all in favour of OSGi and adopting the terminology but its not really clear who would win from this. There would be some from the OSgi community who would be less put off but ultimately the function provided is compelling well beyond any choice of name. I think the original request is a bit far-fetched (and perhaps intentionally to create some debate), but I think there could be some move in this direction without going all out. I've been doing a bit of hacking on "pure OSGi" code lately and see the word plugin appear in inappropriate places. For example, the "OSGi Framework" launch configuration has a "Plug-ins" tab, and options like "Add Required Plugins" and "Start plug-in automatically". If I want to start a project that targets an only OSGi runtime, I have to select File > New > Plugin Project. It seems like there should be a path through the tooling from an end-user perspective that doesn't use the word "plug-in" if I'm doing pure OSGi-level stuff. Whether this tooling lives in a plugin called org.eclipse.pde.* versus org.eclipse.bde.* doesn't seem that important. Also, plugin.xml doesn't bother me as a file name at all - it only contains information that is *not* related to strict OSGi-level bundles. In fact, a pure OSGi developer may be confused by a bundle.xml that is really not related to OSGi at all. (In reply to comment #4) > I think the original request is a bit far-fetched >(and perhaps intentionally to create some debate) You know I like to stir the pot a bit :-P >, but I think there could be some move in this direction > without going all out. I've been doing a bit of hacking on "pure OSGi" code > lately and see the word plugin appear in inappropriate places. >For example, the > "OSGi Framework" launch configuration has a "Plug-ins" tab, and options like > "Add Required Plugins" and "Start plug-in automatically". If I want to start a > project that targets an only OSGi runtime, I have to select File > New > > Plugin Project. > It seems like there should be a path through the tooling from an end-user > perspective that doesn't use the word "plug-in" if I'm doing pure OSGi-level > stuff. Whether this tooling lives in a plugin called org.eclipse.pde.* versus > org.eclipse.bde.* doesn't seem that important. Good point. May be a little UI massaging could go a long way. We already have a a OSGi launch conf. For instance, you could imagine just a simple new Bundle wizard that could re-use most if not all the actual PDE ui wizard pages, yet provide some wording that makes immediate sense for a bundle developer. The Plugin manifest editor could benefit of a little massaging too, I guess, adn could have a Bundle manifest editor incarnation. Philippe, you lost me at Bundle Manifest Editor. ;) I am not sure how different that would be from a regular plug-in manifest editor. Would it filter out extension pages? We already have that filtering functionality. Why stop there? why not Bundle Import wizard, bundle export wizards, bundles view, a bundle project nature, etc.? Let's in fact double the size of PDE by providing a duplicate set of all PDE contributions, with the exception that the new set uses the word 'bundle'. If the remedy is, as suggested here, just a few messages here, isn't that a proof that the distinction between bundle and plugin is artificial? How can we one decide what's a plug-in and what's a bundle? I do agree however that it may be appropriate to change the wording in the OSGi Framework launcher. (In reply to comment #6) > Philippe, you lost me at Bundle Manifest Editor. ;) I am not sure how > different that would be from a regular plug-in manifest editor. Would it > filter out extension pages? We already have that filtering functionality. It would not be different. The way I see it it is really cosmetic. > Why stop there? why not Bundle Import wizard, bundle export wizards, bundles > view, a bundle project nature, etc.? Let's in fact double the size of PDE by > providing a duplicate set of all PDE contributions, with the exception > that the new set uses the word 'bundle'. > If the remedy is, as suggested here, just a few messages here, isn't that a > proof that the distinction between bundle and plugin is artificial? It is artificial, yet mostly an implementation detail when it comes to Eclipse. However, when you are a bundle developer building on top of OSGi that sounds weird. There is a good momentum building up behind OSGi, with new frameworks, services, and adoption poping up everywhere. Eclipse with PDE has the opportunity to establish itself as the standard tooling in that space. So yes this is mostly about marketing. Yet this can be important too. I am renaming this puppy, so it matches better what this could realistically be about This one comes up from time to time. Seems like the only way to address it (if at all) would be to consistntly rename all the wizards, views, lists, ... and expunge the word "plugin". To do otherwise would likely confuse peopel more because someplaces we talka bout plugins and others about bundles... I thought they were the same thing! Having said that, there do appear to be some barriers to entry where people go looking for "bundle" tooling and see "plugin" tooling. Don't know the answer here. In 3.3M6, all references to 'Plug-ins' in the OSGi Framework Launcher will be replaced with 'Bundles'. 'Plug-ins' is inappropriate in this context. One small step for A man... (In reply to comment #9) > Having said that, there do appear to be some barriers to entry where people go > looking for "bundle" tooling and see "plugin" tooling. If in this context bundle == plugin, then what's the problem? Surely people will survive if they have to search for two keywords instead of one? Consider: keys, keybindings, bindings, mappings, assignments... feature, function, group, capacity, enablement... UI, GUI, interface, tool, tooling... base, platform, framework, api, spec... Or, to put it another way, instead of 'Rebuild, Reuse, Refactor', why not just 'Promotion, Documentation, Education'? You mean that's not what PDE stands for? Damn. ;-) On the PDE welcome page, why not just say "blah blah plug-ins (or OSGi bundles) blah blah..." or "blah blah OSGi bundles (also known as plug-ins) blah blah..." ? Surely it's easier to insert a few buzzwords when you're updating docs every year than it is to refactor all of PDE UI, no? *** Bug 272537 has been marked as a duplicate of this bug. *** from my POV it would be a great idea to use bundle instead of Plug-In. at the moment I'm always talking about Plug-In (Bundle) or Bundle (Plug-In) or Bundle == PlugIn. in reality for me its the same - then it would be much easier only to use Bundle. of course it would take some time to change it everywhere, but at the end it'll be much easier to understand ekke As a user who does mainly eclipse development there is a distinction to me between an osgi bundle, and an eclipse plugin. Mainly, the plugin.xml file that eclipse plugins may need for working with extension points. My understanding, limited that it is, is that a OSGI bundle does not need or even care about the plugin.xml file. That file is entirely eclipse specific. So yes, while eclipse plugins are OSGI bundles, they are an extension mechanism left over for compatibility reasons with eclipse's prior architecture. I can't necessarily take any eclipse plugin and deploy it on any osgi service, especially if it uses eclipse specific customizations and extension points. So, ideally, you could combine to a common wizard for doing OSGi/Eclipse plugins, just have an additional page or question asking if it's an eclipse plugin, then do these additional wizard pages. You could also reuse the same Editor tabs, but based on the availability of a plugin.xml file, certain tabs could be made available, and at other times hidden. Just my two cents. (In reply to comment #14) > As a user who does mainly eclipse development there is a distinction to me > between an osgi bundle, and an eclipse plugin. There is no difference. > Mainly, the plugin.xml file that eclipse plugins may need for working with > extension points. > My understanding, limited that it is, is that a OSGI bundle does not need or > even care about the plugin.xml file. That file is entirely eclipse specific. The same way OSGi doesn't care about "Declarative Services" component.xml files. In the end, the extension registry is a glorified implementation of the famous OSGI extender pattern (http://www.osgi.org/blog/2007/02/osgi-extender-model.html). In the end, that file is "Extension Registry" specific, the same way the component.xml files are "DS specific". > So yes, while eclipse plugins are OSGI bundles, they are an extension mechanism > left over for compatibility reasons with eclipse's prior architecture. I > can't necessarily take any eclipse plugin and deploy it on any osgi service, > especially if it uses eclipse specific customizations and extension points. Sure, you can take bundles developed on Eclipse and deploy them to other OSGi frameworks. We do this all the time actually. The extension registry even runs on other frameworks. > So, ideally, you could combine to a common wizard for doing OSGi/Eclipse > plugins, just have an additional page or question asking if it's an eclipse > plugin, then do these additional wizard pages. > > You could also reuse the same Editor tabs, but based on the availability of a > plugin.xml file, certain tabs could be made available, and at other times > hidden. We already do this. Try to create a new plug-in project and choose OSGi as the target. +1 for renaming PDE to BDE and generally switching from the use of "plugin" to "bundle". I really hope this makes it into 3.6 or 4.0. As an RCP trainer, I'm switching all of my materials to use the term "bundle" and I describe "plugin" as deprecated terminology. Terminology matters, and I think it's important for RCP developers to understand that they are using OSGi and should be using all of the tools provided by the framework. Also, I think the usage of Eclipse tooling to create non-RCP/plugin OSGi applications is going to increase rapidly. It's important that we provide tooling that makes sense to those developers. It's true that plugin.xml is non-standard and we need to deal with this conceptually. In terms of wizards/tooling, we may want to start thinking about OSGi Core as a baseline and then ask people what they'd like to add. Do you want to use extension points? Declarative services? Eclipse Core Runtime? Eclipse UI? It might make sense to combine the Target Platform section of the Plug-in Project Wizard with the "Contributions to UI" checkbox and create a one-stop-shopping for additions to OSGi Core. Just thinking out loud here. As for the term "feature", I don't have a problem with it right now. Other platforms (e.g. ServiceMix) have similar concepts. I would vote to wait until a standard exists and then rename at that time. +1 for making the change to bundles as the common terminology. I think there is a lot of support for moving to 'bundles', but what we really need is a proposal on how to implement the changes. This will affect a lot of people (Eclipse SDK developers, the Foundation, Eclipse Plug-in Central, RCP developers, etc.) so we want the transition to be clearly laid out. (In reply to comment #18) > I think there is a lot of support for moving to 'bundles', but what we really > need is a proposal on how to implement the changes. This will affect a lot of > people (Eclipse SDK developers, the Foundation, Eclipse Plug-in Central, RCP > developers, etc.) so we want the transition to be clearly laid out. Eclipse Plug-in Central will be known as Eclipse Marketplace (soon) In terms of what to do, the first steps would be to simply deprecate the term plug-in and use bundle. (In reply to comment #16) > +1 for renaming PDE to BDE and generally switching from the use of "plugin" to > "bundle". I really hope this makes it into 3.6 or 4.0. > +1 from me as well. > It's true that plugin.xml is non-standard and we need to deal with this > conceptually. In terms of wizards/tooling, we may want to start thinking about > OSGi Core as a baseline and then ask people what they'd like to add. Do you > want to use extension points? Declarative services? Eclipse Core Runtime? > Eclipse UI? It might make sense to combine the Target Platform section of the > Plug-in Project Wizard with the "Contributions to UI" checkbox and create a > one-stop-shopping for additions to OSGi Core. Just thinking out loud here. Chris this is the point I was making. An "bundle" that is targeted for eclipse that uses eclipse's extension points is still an "eclipse plugin". It won't work unmodified because that extension point that is specific to eclipse won't be there unless it is deployed there as well. (In reply to comment #14) >Chris this is the point I was making. An "bundle" that is targeted for >eclipse that uses eclipse's extension points is still an "eclipse plugin". It >won't work unmodified because that extension point that is specific to eclipse >won't be there unless it is deployed there as well. I think the best way to look at this is that all bundles have dependencies, and the wizard can help users set some of these up. If you want declarative services, then you need the ds bundle. If you want to use extension points, you need the extension registry bundle. It doesn't really matter whether a dependency is Eclipse-specific or not, it's just another bundle dependency. It's true though, that this places more demands on developers in terms of understanding what's going on, but this might be a good thing. Last reply was in response to comment #20, not #14. (In reply to comment #20) > Chris this is the point I was making. An "bundle" that is targeted for > eclipse that uses eclipse's extension points is still an "eclipse plugin". It > won't work unmodified because that extension point that is specific to eclipse > won't be there unless it is deployed there as well. Here is another view. What if the extension registry bundle is deployed together with other bundles defining and using extension points on Felix. Do they now become "Felix Plug-ins"? IMHO the term "Eclipse Plug-in" plays well as a marketing name for Eclipse IDE extensions. Frankly, when I recommend something to somebody what to install to have support for XYZ in Eclipse I often use the term "Eclipse Plug-in". For example, just install the "Subclipse Plug-in" or hey there is an open source "Eclipse plug-in for ClearCase". But technically this would be incorrect. It's not a single "plug-in". Those are features with a couple of bundles underneath. +1 Eclipse plug-ins are bundles, which extends the Eclipse IDE and nothing else. Plug-ins are not the bundles, which are deployed on Equinox platform and still uses Eclipse specific extensions, so Eclipse plug-ins are a subset of OSGi bundles. PDE is perfectly suitable to support OSGi bundles development. (In reply to comment #23) > IMHO the term "Eclipse Plug-in" plays well as a marketing name for Eclipse IDE > extensions. Frankly, when I recommend something to somebody what to install to > have support for XYZ in Eclipse I often use the term "Eclipse Plug-in". For > example, just install the "Subclipse Plug-in" or hey there is an open source > "Eclipse plug-in for ClearCase". But technically this would be incorrect. It's > not a single "plug-in". Those are features with a couple of bundles >underneath. I agree with Gunnar in that the term "Eclipse Plug-in" is entrenched in the community to mean a unit of function that can be installed into the platform. In addition to that, a large base of existing products use the term "plug-in" in documentation, cheet-sheets, tutorials, and marketing information. So although this can be viewed as a cosmetic change, I think we need to be conservative in the 3.x streams for compatibility purposes. It sounds like a simple change, but the side effects and migration efforts are far reaching. I'm also curious how the Eclipse foundation views this issue. At the tooling implementation level, I think it would make sense to think about how we could re-architect things to be based on a pure OSGi bundle model and be more extensible for add-ons such as the plug-in registry and declarative services. For example, it might make sense for each level of tooling to have its own nature/builder provided by separate bundles (plug-ins :-), and as already suggested - a project creation wizard that lets you choose the features that you want to have in your bundle. Perhaps we can get 80% of the fun for 20% of the effort here. I don't think anyone was really expecting the entire Eclipse community to change to use "bundle" so things like doc, web pages, EPIC/Marketplace, ... are not really at play. What is interesting (and tractable IMHO) is to offer OSGi/Equinox folks some clarity and make the tooling attractive. Frankly, most people don't understand any of this stuff. From the OSGi point of view the concerns we hear in training and talking to quite a few people are: - want to use OSGi - don't want to be locked into one framework/vendor - Eclipse is big - PDE is for developing Eclipse plugins - We are not running Eclipse, we want to run OSGi My thinking is that a few simple changes to the PDE UI messages would go a long way. Looking over the manifest editor for example, pretty much every sentence has the word "plugin" in it. Typically it is redundant (itis a plugin editor after all) and could be reworded to be agnostic. With that messaging tweak, we could present things like New Bundle Project that just end up running what is now the New Plugin wizard. A few more things like that and away we go. I don't know how much time we have to explore this in 3.6, but here's my rational on when to do the actual change. We are getting a donation from SpringSource as part of Virgo which includes some of the SS Tooling stack (things like Bundlor). When we start doing this merge, I will use this as an excuse to start making the terminology change in various areas. Note that we went to the eclipse-pmc last time to ask that the platform start changing the way it's talking about plug-ins vs bundles but it kinda fell on deaf ears (well, it was really viewed as too big of a change at the time) [1]. [1] - http://dev.eclipse.org/mhonarc/lists/eclipse-pmc/msg00775.html *** Bug 167438 has been marked as a duplicate of this bug. *** This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the stalebug whiteboard tag. |