- Check the rich client log, available via Help - Support - View Trace. Enable trace logging for the widgets and provisioning subsystems to find out what is happening.
- Look at the features and plugins that have been installed in the user’s install site:
- Check the platform.xml file to see which features are enabled. Only installed and enabled features are recognized at runtime.
Hunter's ISSL Blog
HunterMedney 1100009YKB Marcações:  provisioning notes8 troubleshooting widgets 1 Comentário 4.442 Visualizações
Below are areas to look at when troubleshooting install/update/removal of Eclipse features and plugins via widgets.
HunterMedney 1100009YKB Marcações:  notes notes8 widgets best-practices provisioning 6.611 Visualizações
Lotus Notes 8 Standard offers an elegant deployment mechanism for pushing and pulling of Eclipse features & plugins which leverages the Domino infrastructure and its strengths (high availability, security, offline, policies, synchronization, …). The mechanism is called “Drag-to-Install” and works primarily through a special Domino database called the "widget catalog” and a sidebar application called “My Widgets”.
A widget catalog contains widgets, and widgets are XML documents describing dynamic contributions/extensions to the Notes 8 Standard client. End users drag a widget from the catalog to the “My Widgets” sidebar to install a widget. Installing a widget adds something to the client, like a web page, LiveText content, search engine, Notes object on the sidebar and, of course, Eclipse features & plugins. Likewise, whatever was added is removed when the user removes the widget from “My Widgets”.
In addition to dragging-and-dropping widgets from the widget catalog, the widget XML documents (normally named “extension.xml”) can be drug from the file system or a web server. “My Widgets” basically accepts URLs ending in “extension.xml”.
What a widget does is based on the widget provider and configuration info defined in the widget’s XML. Furthermore, widgets can also make dynamic contributions to Eclipse extension points. In many cases, much of a widget’s work is done through these dynamic extension points.
Both the allowed widget providers and the allowed dynamic extension point contributions can be optionally restricted on clients using a Domino Desktop policy. The Desktop policy can also restrict how users install and share widgets.
One of the widget providers is “com.ibm.rcp.toolbox.prov.provider.ToolboxProvisioning” which invokes the feature/plugin provisioning engine in Lotus Expeditor with a provisioning manifest defined within the widget. Provisioning manifests direct the provisioning engine to install, enable, disable and uninstall Eclipse features. When you configure a new “Features & Plug-ins” widget using the wizard available in Notes 8.5.1, it creates a “com.ibm.rcp.toolbox.prov.provider.ToolboxProvisioning” widget with a provisioning manifest that installs the specified feature(s) from the specified update site.
The following provisioning widget XML contains a provisioning manifest (see the <installManifest> element). The manifest tells the provisioning engine version “126.96.36.199002020358” of the “org.testing.app1” feature needs to be installed. If not already installed, get from update site “nrpc:///__852576be00571335/site.xml”.
Provisioning manifests list Eclipse features that should be present in the platform, at what version levels and where to get the features if not present. Note the “match” attribute on the feature element above – this determines what version(s) of the feature are required on the platform in relation to the version attribute provided in the manifest. “perfect” means a feature with that exact version number must be present in the platform. “compatible” means the feature must have the first 2 version digits in common, e.g. 1.0.1 and 1.0.2 are both compatible with 1.0.0. See the provisioning manifest DTD for reference.
A word on features vs plugins
Plugins contain the executable code, and features package plugins for deployment. Hence deployment activities (aka provisioning) deal with features, not plugins directly.
Plugins are only installed if a feature includes them on its the “Plugins” tab. Plugins are not automatically installed if a feature or other plugin just declares a dependency on them.
Furthermore, only those features which have been provisioned are recognized by the platform. Plugins are only recognized if they are part of a recognized (installed and enabled) feature. This is in contrast to plain Eclipse which recognizes all features and plugins present in its install site folder(s).
Provisioning widget best practices
And without further ado, best practices to consider when packaging Eclipse features and plugins for deployment via widgets.
Deploying shared/common features via widgets
Suppose your company wants to roll-out 2 sidebar applications via widgets. Each sidebar application naturally has it’s own plugin, feature and provisioning widget. Users can drag the widget for each application to their sidebar, and this will cause the application’s feature/plugin to be installed. So far, so good.
Now suppose those 2 sidebar applications use a common plugin which is not part of the product and must also be deployed through the widget mechanism. Also suppose the common plugin has a different update cycle than the 2 sidebar applications. What’s the best way to package your features and provisioning widgets such that:
Follow these rules to meet the above requirements:
TroubleshootingSee this post.
HunterMedney 1100009YKB Marcações:  notes eclipse widgets provisioning customization notes8 branding 1 Comentário 4.548 Visualizações
Widgets provide a nice mechanism for deploying Eclipse features and plugins to Lotus Notes 8 Standard clients. These widgets can be created using a wizard provided in Notes 8.5.1 (below) or manually.
Widgets are XML documents that describe dynamic contributions/extensions to the Notes 8 client. Part of the widget XML is an imageUrl attribute for an optional image for the widget. As the number of installed widgets grows, images can be useful to distinguish among them.
While it may make sense for web widgets to get their icon from the web site, like /favicon.ico, provisioning widgets (widgets that install plugins) may want to use an image inside the plugin itself.
If no image is specified, a default image is used:
So what do we put in imageUrl that will reference an image inside a plugin? The Eclipse platform supports a special “platform:” URI which enables us to provide a URL to a resource inside a plugin. The URL for image “/icons/sample.gif” in plugin “foo.myplugin” is:
Below is a provisioning widget’s XML (extension.xml) which installs 2 Eclipse features and specifies a custom image for the widget.
Here is how the provisioning widget looks in “My Widgets":