Community
Participate
Working Groups
Bugs to track the discussion about adding a markup to express bundle dynamic capabilities. Initial RFC is at http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-core-home/documents/rfc/0010/dynamic_capabilities.html
The section on Default Values says: >Default values > >For the manifests being generated from a plugin.xml the value generated will >be:Eclipse-Dynamic: enabled. This captures the good practice that has been >indicated since eclipse 1.0 that plugins must clean up after them in the >shutdown method. This seems to be the opposite of what we really want. It seems to me that it is not safe to assume that a plugin will do the right things unless it specifically claims to do so. Basically, a plugin should be required to state explicitely that it IS dynamic enabled before it can be treated as so and thus can be uninstalled dynamically with no restart needed. This is a straightforward practicality in the face of the fact that the vast majority of existing plugins that do not have manifests are not going to be safe to assume they are dynamic. The default value for manifests generated from plugin.xml should be that they are not dynamic enabled. I.E. - this header should not be added when the manifest is generatated automatically at plugin load time. Thus, the only way a plugin could be considered dynamic enabled is if it is a new (v3.0) plugin with an actual manifest of its own and with the Eclipse-Dynamic: header already set. It might be reasonable to have 'enabled' be the default value in manifests generated in the PDE when developing a new plugin. Am I being too cautious?
Agreed. Default should be conservative. In fact, I suspect that many/most plugins are NOT Dynamic Enabled as they likely do not clean up after themselves by removing listeners and removing things from ImageRegistries etc. On a different note, I am not a fan of adding to the plugin.xml. Without that however we will be forcing people writing dynamic plugins to write manifest.mf files (They need a way to add the dynamic markup). Our initial position on plugin.xml vs manifest.mf was that the current plugin.xml would be preserved but new things would go in the manifest. The impact of this needs to be clear to people.
1. Don't you need a value for 'not enabled' and one for 'unspecified'? Default would be 'unspecified', which the platform could take to mean not enabled or enabled depending on how trusting it wants to be (see earlier comments). 2. I'd like to be able to specify dynamic-enabledness without a manifest.mf. Maybe in a special block like the version number uses, or an optional attribute on the plugin element. Justification: So far I've avoided using manifest.mf and given it's subject to change (for example as OSGi adopts Eclipse-isms into the standard) and it's marked as an 'advanced feature' and it's more complicated to explain to new plug-in developers I'd like to keep avoiding it if possible. Currently I'm content for manifest.mf to be completely behind the scenes. Making too much stuff API will tie the hands of future platform-core developers.
How do you propose we handle "normal" OSGi bundles? These are bundles that have been developed for other OSGi frameworks. A majority of these bundles ARE dynamic aware and never require a restart when bundles are installed/updated/uninstalled. These bundles will not have the Eclipse- Dynamic header and therefore will not be dynamic aware according to the default value of the Eclipse-Dynamic header. Would configurators/installers force a restart when these bundles are updated/installed/uninstalled? Or do we only pay attention to this header when a bundle has an extension or extension point?
Peter Kriens said: I think the default is reversed. OSGi bundles are by default dynamic. It is unlikely that OSGi bundles, which work perfectly OK under Eclipse, would not be seen as dynamic. An Eclipse-Static header seems to make more sense because you could automatically add it when you generate the manifest from the plugin. Kind regards, Peter Kriens
I just posted an updated version of the document. The changes are around the default values. Here is a recap: - unspecified value added - pure osgi bundles will be considered "enabled" to reflect the osgi reality. - 3.0 plugins with a manifest should review the code and set the value - 3.0 plugins with a plugin.xml (manifest being generated) default value is "unspecified" There will be no support in the plugin.xml. Marking dynamic capability is only interesting for people writing dynamic plugins and we consider that they should use the manifest which is the new way of expressing dependencies. Moreover PDE is likely to provide first class edition support for manifest.mf in 3.1 to blur the distinction even more.
There are currently many eclipse plugins which are addition aware, so this proposal will force all of them to use a manifest. What's wrong with adding another optional attribute to the <plugin> element in plugin.xml ?
Hummm... plenty of reasons let me see: - Plugin.xml is history <g> - If the syntax of the plugin.xml is changed a lot of code will have to be changed. - Tools willing to use those tags they will have to be able to understand both plugin.xml and manifest.mf. Note that parsing XML is heavier than reading a manifest for which helper class exists. - Having the markup in both place is confusing. - PDE provides a nice editor that seamlessly allow me to edit the plugin manifest (plugin.xml and manifest)
okay, so let me summarize my interpretation of the spec so far based on your latest changes. Define a 'pure OSGi bundle' as a bundle without a plugin.xml. Define 'eclipse plugin' as a bundle with a plugin.xml. It may or may not have a manifest.mf. Define a 'modern eclipse plugin' as an eclipse plugin with a manfifest.mf. [Q: What about plugin that has an <?eclipse version="3.0"?> tag, but no manifest.mf? How is that to be treated? I'll assume like a legacy plugin.] For pure OSGI bundles, the default value is assumed to be 'enabled'. Are they also assumed to be addition/deletion aware? For modern eclipse plugins, they should indicate the Eclipse-Dynamic: header in the manifest. This will be inserted by the PDE at development time in the future. Can be manually added/changed by the developer otherwise. It is expected that usually modern plugins will use some combination of 'enabled', 'addition-enabled' and/or 'deletion-enabled', but some might set 'unspecified' explicitely. If the manifest.mf is there, but this particular value is not specified, then the default value is what? Enabled? Unspecified? My conservative streak says it should be Unspecified. For legacy eclipse plugins, when the manifest is auto-generated during load-time, the default value will be 'unspecified'. USAGE: If the value for a bundle is 'unspecified' then the bundle should NOT be considered able to handle dynamic changes to its dependency scope within the configuration. That is, if one of its dependencies or dependents gets added/removed, or if this bundle itself gets added/removed, then a restart would be assumed to be necessary. If the value for a bundle includes 'enabled' then the that bundle may be added/removed without a restart, provided all its dependents/dependencies are addition/deletion-enabled. If the value for a bundle includes 'addition-enabled' then that bundle is okay if a dependent/dependency is added. If the value for a bundle includes 'deletion-enabled' then that bundle is okay if a dependent/dependency is removed.
Mel let me first refine your description. There are mainly two types of things we are dealing with: 1) pure osgi bundles 2) plugins, for which there is two types (whether <?eclipse version="3.0"?> is present is irrelevant) a) plugin with a plugin.xml only (for example some 3.0 and all the 2.1 plugins) - legacy plugins b) plugin with a manifest.mf and a plugin.xml - modern plugins Pure osgi bundles will not have the Eclipse-Dynamic header and we can not expect to be able to modify them. After all, they just happen to be running in eclipse. The idea I was trying to capture in the document is: "it is recommanded for tools to consider pure osgi bundles as dynamic enabled". "addition-aware" or "removal-aware" are meaningless in this context. Note that if it helps a tool to consider other values as default, it is up to it. A modern plugin that would not have specified a value would fall under the same category than a pure osgi bundle. That's why in the proposal, it is recommanded to check the values of the manifest.mf. Of course here again, since those values are advisory a tool can decide otherwise and do more check. Note that we expect that all of the RCP plugins will have this tag. Maybe the proposal should force people that have a manifest to set the value as a step to move to 3.1? For legacy plugins the value will be set to 'unspecified' by the manifest generator. It is the only case where actually a value is "forced" instead of being indicated by a user. In complement of defining the new header the goal of the document is to define a rough guideline on how to deal with the default cases, however this can be refined by every tool. That's why I'm commenting on the usage/interpretation you are doing of the values. Of course it would be best if everybody agreed :-)
In addition to Pascal's comment 8: we have done this (require bundle manifests) during the 3.0 cycle already for selective plug-in activation. PDE plug-in manifest editor requests the developer to start using a MANIFEST.MF in order for him/her to take advantage of selective activation support (see the "Runtime" tab, "Plug-in Activation" section).
True but selective plug-in activation is much more esoteric than dynamic awareness. Every plug-in currently running in the system will need to be marked as addition- and removal- aware in order for the Update manager to upgrade an already installed feature without restarting the workbench, right? Which means if we ever want Update to do this (I do), then every plug-in in the Platform SDK plus every plug-in the user has installed (Perforce team provider, XML editor, whatever) will need to migrate to manifest.mf even if it didn't actually need a code change. That seems harsh. Is manifest.mf and its syntax even considered API?
Every plug-in that can actually react properly to dynamic changes. I assume that, at this moment, many are not, so they do not require any changes. Making a plug-in dynamic is not a trivial task in many cases, so migrating to using a bundle manifest should not be the main problem. The manifest.mf syntax is defined by the OSGi spec, so it sure is not just an implementation detail. AFAIK, those headers added by Eclipse itself (the one discussed here and the Eclipse-AutoStart for instance, among others) are intended to be API, as well. We imagine that at some point in the future, all plug-ins have plugin.xml files that describe their extension and extension points only (see org.eclipse.core.runtime's), if they have any, and all other description is specified in bundle manifests. For that to happen, better/more complete tooling for bundle development is necessary, and that is planned.
To emphasize Rafael last point: If a plug-in is marked as "enabled" or *-aware, it is a strong statement and any incorrect behavior (leaks, registry not tracked, etc.) will be a *bug*. Therefore marking a plugin is *not* a thing you just so it avoids restart. It is somehow an API statement of the behavior of your plugin. Note as well that there is no plan to make the full SDK fully dynamic-aware (it is however probably 'enabled'). I think the best we can hope for is to have the RCP SDK fully dynamic.
Regarding comment#12 - I don't see that every plugin in the runtime would need to be additiona/deletion aware in order to support adding/deleting a bundle. Only the bundles within the dependency scope of that bundle (i.e. - those that can see / be seen by the particular bundle) would need to be aware.
A few points: - re: comment #14 I actually doubt that many plugins are "enabled". Being enabled means that plugins correctly unhook listeners etc when they are stop()'d - re: comment #15 The dependency scope does not capture the extension/extension point interactions. There is no need to say that A depends on B if A contributes an extension to B etc etc.
Good point Jeff - in my mind I was including the implicit dependency of extension point usage. However, how 'hard' of a dependency this might be is pretty variable. How do we characterize this? It seems like this should be resolveable. It would seem an overly onerous requirement to insist that the entirety of the runtime is addition/deletion aware in order to add/delete a plugin (that has limited scope of interaction within the runtime). In some sense, as Pascal indicates, this is up to the tooling to decide how to handle. However, we probably should establish the basic rules and algorythms that all tooling would expect to conform to.
I agree that it would be good to refine this. We should be able to do some matching for example, if the plugin being added does not have any extensions then the need for the others in the system to be dynamic aware is *reduced*. If the plugin being added contributes extensions only to plugins which are aware then again, the need is *reduced*. I highlighted the *reduced* because enablement and awareness are not only registry related. For example, if some plugin gathers up and retains a list of all other plugins that are installed and is not aware, then adding/removing other plugins will put it in an inconsistent state. If the author of that plugin doesn't care about this then they can mark themselves as aware. In effect, the markup (or lack of) indicates whether or not they want to request a restart when things change. Summary: There are some things which could be done but they will be imprecise and incomplete. The question we have then is "is the complexity of doing, managing and explaining this worth the less than optimal results?"
Re: comment #17 and comment #18: Take a plugin P that defines an extension point EP. Assume that P cannot process extensions to EP dynamically (i.e. if new plugins get installed and contribute extensions to EP, P will ignore them). To behave correctly, P cannot declare it is addition-aware. So, based on this, any installation containing P is doomed to be restarted upon installing any new plugin, even though those plugins would have nothing to do with P. To me, it looks like addition-aware should imply that a plugin is ok with installing new plugins that extend it. However, if plugin relationships are to be looked at, the arguments in comment #8 are not all valid, as plugin.xml will have to be parsed and looked at. API's: Do you plan any API's for install agents (such as update manager)? For example, update manager could create a "virtual configuration" that includes the newly installed/uninstall/updated plugins, and the runtime can be asked whether this configuration can just be "applied" without restarting, etc.
One thing that has been missed in the usage of the tag is "when do we do the analysis?". Do we do it before even installing (provisionning) the plugin into osgi, or do we do it after the installation (and refresh). In the first case: doing a full analysis of the extension / extension point model does not seem to be tractable, since a plugin registry would have to be recreated. In the second case it would be possible to have all the information about extensions and extensoin points but I'm not sure we would gain a lot from it. Indeed even though it is true that extensions are not tight to bundle prerequisite, the reality is that a vast majority of plugins require the plugin to which they contribute an extension. Another thing that has been omitted in the tooling conversation is the state of the bundles (mainly ACTIVE or not). For example it is probably okay to install a plugin if its prereqs are not started. I've tried to come up with a table indicating whether or not the system should be shutdown if a plugin B was installed and required the plugin A (B capabilities are in rows and A in columns). Y indicates that the system must be shutdown and N that it can be kept running. The first letter captures B' addition and the second its removal. For example, the second row, first column indicate that you do not have to restart when B (an enabled plugin) is added and requires A (a add-aware only plugin). It shows that when B goes away the system has to be shutdown. A \ B enabled add-aw rem-aw all enabled Y(1) Y(2) Y(1) Y(2) Y(1) Y(2) Y(1) Y(2) add-aw N Y(2) N Y(2) N Y(2) N Y(2) rem-aw Y(1) N Y(1) Y(4) Y(1) Y(4) Y(1) N all N N N Y(4) N Y(4) N N 1) A will does not see B coming 2) A will not see B leaving 4) B won't clean up after itself since it is not enabled
About the API, org.eclipse.osgi.service.resolver.State and org.eclipse.osgi.service.resolver.PlatformAdmin should help you to figure out the dependencies and do the computation. PDE core and PDE build have code that already uses it.
I updated the document. It includes changes in the section to compute the default values and the way tools should behave.
Thanks, Pascal. This draft looks real good.
Is everybody happy here? I'm planning to start tagging the RCP plugins for M5, and provide snippets of code on how to use the values for M6 (unless someone already implemented it before? :-)
The defaults in the document are not clear. For example, what is the value for a plugin with just a plugin.xml? I know the converter will generate one but what is it? Can you post a table/list that has all the cases with the defaults.
The proposal has been updated with an explicit list of values.
I'm not sure this will happen for M6.
need to consider the API implications wrt M6 API freeze. We should talk to Jim about adding this after M6.
I was not thinking on introducing new APIs for that purpose in 3.1.(except the markup in the manifest). My goal here was to provide a snippet of code for people to use as a base.
This won't be addressed in 3.1
It seems that there is no plan to implement this. Please feel free to re-open if there is still an intention to implement this.
*** Bug 289583 has been marked as a duplicate of this bug. ***
Reopened based on interest expressed in bug 289583.
*** Bug 314942 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.
