Community
Participate
Working Groups
Currently most Elcipse plugins are marked as singletons because they contribute to the registry. In effect the registry namespace is a shared resource and there can only be one user of a given name. This is somewhat problematic in scenarios where say you are interfacing to multiple database that might use different levels of JDBC or multiple versions of a chat/conferencing protocol or... In our review of the registry code, it would be interesting to see what it would mean to allow multple versions of a plugin to contribute registry elements. This is similar to the issues faced by the OSGi service registry in managing multiple versions of a service type. Basically which one is used depends on who is looking. you only see the one that you should see. Not quite sure how this maps onto the registry but its worth bending our minds around it for a bit.
I doubt anything will be done here for 3.3. Oleg? Please remove milestone if we are not addressing this for 3.3.
There are no plans to implement this enhancement. While interesting for some usecases, it opens a question of having duplicate registry elements. Couple it with with unfortunante fact that extensions IDs are optional, and it becomes very unclear. (Filtering registry contents based on "who's looking" is problematic as links established by OSGi resolution are not necessary duplicated in the extension <-> extension points relationships.)
*** Bug 208570 has been marked as a duplicate of this bug. ***
*** Bug 189770 has been marked as a duplicate of this bug. ***
*** Bug 137574 has been marked as a duplicate of this bug. ***
The description includes two valid scenario related to multiple database that might use different levels of JDBC or multiple versions of a chat/conferencing protocol. In addition to these scenarios, composite applications for IBM Lotus Notes would also benefit from this enhancement. A composite applications is assembled from components to provide on-the-glass integration. A component can be an Eclipse plug-in containing one or more SWT Views. A component is a reusable coarse grained asset which can be created in your company, purchased from a business partner or available as open source. One of the benefits of composite applications is the ability for an application assembler, different from a component developer, to create composite applications from different components. This separation of roles is very powerful, but also makes it more difficult for a component developer to release components which are backwards compatible because they do not know who is using their component and how it is being used. Currently, component developers can use the Eclipse platform plug-in manifest to mark each component with a version. The composite application assembler can specify which component version to use, but since components are singletons (result of extending SWT view), two composite applications in the same Eclipse runtime can't use different components specified using versions. This enhancement request would support this scenario by allowing multiple component versions to be loaded and referenced by different applications. This would provide the required granularity to applications assemblers to reference the appropriate version of a plug-in. Can this enhancement which is currently marked as "no plans to implement" be re-evaluated for a future release.
To be clear, extending SWT or Jface classes does not drive singelton-ness. In the context of this bug it is contirbuting views (whatever) via the extension registry. I'm going to reopen this bug in the context of e4 work. Not sure if we have a keyword or something that we could use to indicate an e4 candidate...
(In reply to comment #7) > To be clear, extending SWT or Jface classes does not drive singelton-ness. In > the context of this bug it is contirbuting views (whatever) via the extension > registry. > In this context I believe Craig is referring to views as extension definitions to the org.eclipse.ui.views extension point which are effectively singletons. > I'm going to reopen this bug in the context of e4 work. Not sure if we have a > keyword or something that we could use to indicate an e4 candidate... > A keyword would be useful. Should we target 4.0 for e4? CC'ing Kevin and Boris to the conversation.
(In reply to comment #8) > A keyword would be useful. Should we target 4.0 for e4? We have been using the 4.0 target milestone for bugs that are relevant to e4/4.0.
true. once we have a real e4 project we can just move the bug there perhaps... anyway, I'll tag this as 4.0 for now.
I have a feeling I am missing something obvious. Let's consider two examples [A] and [B]: [A] Let's say there is a plugin contirbuting a "Hello World" menu. Let's say a given Eclipse installation has this plugin ver 1.1 and ver 1.2. Shall we display both menus from ver.1.1 and ver.1.2 ? Or, if we select one of them, how do we do it? [B] How about two versions of a plugin that provide different menus - "Hello World Classic" and "Hellow World New and Shiny". Same question - do we show both, or how do we select the one to show? Next, try to combine answers for [A] and [B] into a single strategy that would be applicable to both of those cases. (We don't know from plugin.xml if we have [A] or [B].) (Remember that most extensions don't have IDs. Moreover, an extension often has multiple "user facing" objects packed into one extension.) Also note that the answer that is going to be right "most of the time" (such as selecting the latest version of a plugin or trying to match contents of extensions) is not going to be good enough here. Simply due to that fact that extension registry is used a lot, any imperfections that might slide in a "leaf" feature will show up for the extension registry. So the solutions that involve phrases "usually", "most of the time", and "everybody always use it this way" won't cut here :-). I do agree that this would be a nice ability to have. The solution, however, likely going to require non-trivial changes both in the extension registry (which is OK) and its consumers (which is always problematic). It might be more feasable to consider this as one of the requirements for a combined dependency injection story for E4 rather than an enhancement for the extension registry.
In response to your question about Example [A] and [B]: Existing plug-ins who don't use the new ability should behave the current way. In your example, only ver.1.2's menu would be displayed. The new behavior should only come into play when the feature is activated. In that case, all extensions should resolve. In your example, both ver.1.1 and ver.1.2's menus would be shown. Since the plug-in author has specifically chosen to allow multiple versions of their plug-in to be supported, then they are responsible for handling the implications of that behavior. We would want to be sure that those querying an extension point would have the ability to retrieve version information, if they wanted to act upon it. In response to your question about requirement vs. enhancement. I don't understand the process, but I believe it would be fine to make this a requirement for E4 because as you describe the changes might be more substantial then an enhancement.
I also agree with Oleg that this should be part of the overall dependency injection story of E4. At this point we do not know how the solution will look in E4. Will it be based on the extension registry, or something completely different? If something completely different then how will backwards compatibility come into play?
(In reply to comment #12) > In response to your question about Example [A] and [B]: > Existing plug-ins who don't use the new ability should behave the current way. > In your example, only ver.1.2's menu would be displayed. As with many things in eclipse, I do agree that an opt-in strategy will ease the path for adopters. I'll just add for Oleg's examples [A] and [B], you would not be able to put them in a plugin that supported multiple versions. The extension point would not be able to distinguish the different cases ... now that might not be an issue, in that it would be new plugins with new services that specifically can handle the multiple revisions. Maybe extension points themselves must be marked as supporting multiple versions, or you get the legacy behaviour. Just some musings, PW
(In reply to comment #12) > In response to your question about Example [A] and [B]: > Existing plug-ins who don't use the new ability should behave the current way. > [...] Since the plug-in author has specifically > chosen to allow multiple versions of their plug-in to be supported, then they > are responsible for handling the implications of that behavior. I agree with Paul's comment 14. Let's consider the picture of the extension registry world. There are three groups of bundles developed by different people: (1) [singleton] The plugin that declared the extension point. This plugin has extension point declaration in the plugin.xml and, hopefully, a schema for it; (2) [singleton] Plugins that declare extensions. Those plugins have entries in their plugin.xml that correspond to (1); (3) Plugins that do something based on the extensions available for the extension point. Note that (1), (2), and (3) represent different sets of plugins. Often there is some overlap, but generally those are three different sets of plugins from different people. Extrapolating your comment, the code in (3) should be modified to be able to work with non-singleton plugins; and then that code will always receive all extensions? If that is correct, then such change would simply move the burden of dealing with non-singleton plugins from the extension registry to its consumers. This would add a substantial complexity to using the extension registry and would result in lots of [non-trivial] duplicate code added throughtout the Eclipse universe. And this assumes that plugins (3) would know what to do with multiple versions. True, in some cases consumers might have a strategy to deal with it - such as accepting all extensions. However, when I think about the code I've dealt with, most of the code that did not mandate unique IDs on the extensions will have great difficulty figuring this out. As an example, say you have a bundle that contributes a menu. Say, you created a new version of that bundle, with the menu unchanged. After the update, your users have two menu items. If that is not fun enough, think what happens if menus are tied to executable extensions and different versions of Java classes are created by those menus. (Similarly, you can think about an example with source bundles, or contents types, or pretty much anything.) I think that in order to implement this enhancement we'll have to rethink how we approach the extensions IDs and contents of the extensions. [A1] At present extension IDs are optional; hence, there is no way to identify evolution of an extension. The extension IDs have to be made mandatory [A2] At present, the contents of an extension can cover several user-facing element (for example, several menu items), again, with no generic IDs that would allow us to trace its evolution. This has to be changed to either limit extension to one "unit of evolution" or to start assigning IDs to configuration elements Due to the backward compatibility, the notes [A1], [A2] could not be implemented directly. Rather, we'll have to add a notion of a "unit that can evolve" and require those units to provide unique IDs. That would still leave the question as to what to do with the "legacy" plugins. The existing plugins won't have the "units of evolution" specified; moreover, the OSGi will pick up the "singleton" directive that still will be present on the existing plugins.
Tom, can you comment on the OSGi resolver side? What happens if we have: - BundleA ver 1.0 singleton; *and* BundleA ver 1.1 (non-singleton) - BundleB depends on BundleA versions [1.0, 2.0) - BundleC depends on BundleA versions [1.0, 1.1) From what I see in the OSGi doc on the resolver, the resolver is supposed to pick up a highest version that satisfies constraints, which would make a link: BundleB -> BundleA ver. 1.1 At the same time due to version constraints, BundleC can only use ver 1.0: BundleC -> BundleA ver. 1.0 However BundleA ver 1.0 is a singleton so, logically, either BundleB or BundleC will not get properly resolved?
(In reply to comment #16) > Tom, can you comment on the OSGi resolver side? > > What happens if we have: > - BundleA ver 1.0 singleton; *and* BundleA ver 1.1 (non-singleton) > - BundleB depends on BundleA versions [1.0, 2.0) > - BundleC depends on BundleA versions [1.0, 1.1) > > From what I see in the OSGi doc on the resolver, the resolver is supposed to > pick up a highest version that satisfies constraints, which would make a link: > BundleB -> BundleA ver. 1.1 > > At the same time due to version constraints, BundleC can only use ver 1.0: > BundleC -> BundleA ver. 1.0 > > However BundleA ver 1.0 is a singleton so, logically, either BundleB or BundleC > will not get properly resolved? > In OSGi non-singleton versions of a bundle do not effect the resolution singleton versions of the bundle and vise versa. In the case above BundleA ver 1.1 (non-singleton) does not prevent BundleA version 1.0 (singleton) from resolving. So both BundleA ver 1.0 and 1.1 will be allowed to resolve. If you introduce BundleA ver 1.0.1 singleton then it will effect the resolution of BundleA version 1.0, only one of them can be resolved but version 1.1 (non-singleton) will still be allowed to resolve.
Here is a possible preliminary design: 1. IDs and uniqueness. If multiple extension points (ExPt's) with the same qualified IDs are added from bundles, the extension point from the bundle with the highest version number is returned in IExtensionRegistry#getExtensionPoint(ID). The ExtPt for the specific bundle could be retrieved via the new method IContributor#getExtensionPoint() If multiple extensions (Ext's) with the same ID are added from bundles, the Ext from the bundle with the highest version is used. Ext's with no IDs are always treated as separate entitites and associated with the extension point. Clarification: For ExtPt's this means that separate extension points will be created for each bundle version, with latest selected by default. For Ext, extensions with the same IDs will push each other out with the extension from the latest version winning. Ext's with no IDs do not push each other out. 2. Extension -> Extension Point resolution By default, extensions will be associated with all versions of the ExtPt. Optionally, Ext can specify an applicable version range for the ExtPt's contributor. Version range will be the same as OSGi's bundle version range. 3. Event notifications If more recent version of extension is uninstalled, the notifications are sent for the removed extensions and then an attempt made to resolve extensions from the previous versions of the bundle (if any). If resolve succeeds, "add" notifications are send. (Similarly for a higher version bundle being installed.) If bundle containing extension point is uninstalled, the "removed" event is sent for the extension point and all its assocated extensions. If there is an extension point with the same ID from an earlier bundle, the "add" event is sent to indicate that this extension point is being promoted to "default" extension point for the ID. Notes: In an effort to make this design simple, this approach does not consider the refactoring case where Ext or ExtPt are refactored into a different bundle with a different version numbers. A possible resolution for this scenario would be not to rely on bundle versions, but to add explicit versions to the extension points and extensions. Simplicity vs. coverage?
(In reply to comment #18) > In an effort to make this design simple, this approach does not consider the > refactoring case where Ext or ExtPt are refactored into a different bundle with > a different version numbers. A possible resolution for this scenario would be > not to rely on bundle versions, but to add explicit versions to the extension > points and extensions. Simplicity vs. coverage? I was going to ask exactly about this when I read that you want to introduce versions for extension points. Actually, that makes sense and is similar to packages which can also move around between bundles but still keep the version. Having versions would also ensure that an extension is not wired to an incompatible extension point. However, it could get problematic if you install version 4.0 of the extension point which has incompatible changes to version 3.x and you have extensions in place which don't specify a version. Thus, maybe the bundle version must be used as a fallback to prevent wiring of that extension to version 4.0 (assuming that the bundle would not resolve against the bundle contributing 4.0). Another part is createExecutableExtension ... how do you ensure that the objects can be casted to the right interface version without ClassCastException?
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.
