Community
Participate
Working Groups
Bug 281226 discusses the ways in which the update UI should be simpler for RCP apps. We have a number of RCP examples that show how to configure the UI, but those either focus on advanced configuration (changing IU visibility in repos), or are too simplistic (forced update on startup with no UI). We haven't yet built an example that captures the essence of a mildly configurable, simple update UI (with no installing of add-ons). This could easily be done. See the original bug for requirements, but the main idea is to define internal preferences for the things people want to configure without having to write Policy overrides. Package it all up in a feature, and then the app can use the plugin customization file to set the preferences as desired. Voila. What we need: - an example that doesn't contribute any installation pages, preference pages, or install commands, but does contribute the check for updates handler. - include a sample ini file that itemizes all of the existing update check preferences that are currently settable through the pref ui - define prefs for additional policy control (repo visibility, drill down in the update wizard, license management) I'd like to see some people try to use it before worrying about whether this example becomes "officially supported." Since it's a subset of the function in the SDK UI, there wouldn't be much to it besides the custom preferences mapping to the policy. In the end, though, we would probably support this configuration bundle/feature, which might eliminate the need for any officially supported API at all. The API is just the preferences.
Changing milestone (to 3.6 to track for this release). Two reasons: 1) the p2 API changes happening in the branch won't be released until after M4. 2) we need to figure out our story for bug 295273 before proceeding with the branding issues. Questions discussed there include: - does the Mylyn connector support updates (if so this blurs the line between the work going on here and the connector work) - does the Mylyn branding data move into p2 or is there an extra branding/discovery publishing step on the part of a product
Created attachment 162003 [details] patch
The patch makes the org.eclipse.equinox.p2.examples.rcp.cloud application work with M6. One problem I noticed is that o.e.e.p2.ui plug-in has a dependency on org.eclipse.compare. That adds quite a few dependencies for RCP applications since org.eclipse.compare pulls in org.eclipse.ui.ide. The patch marks the dependency as optional but that is not the right fix since RevertProfilePage actually breaks if org.eclipse.compare is missing. Susan, was the RCP use case considered when the dependency was added?
(In reply to comment #3) > The patch marks the dependency as optional but that is not the right fix since > RevertProfilePage actually breaks if org.eclipse.compare is missing. Susan, was > the RCP use case considered when the dependency was added? nope. my bad.
(In reply to comment #0) > See the original bug for requirements, but the main idea is to define internal > preferences for the things people want to configure without having to write > Policy overrides. Package it all up in a feature, and then the app can use the > plugin customization file to set the preferences as desired. Voila. > > What we need: > - an example that doesn't contribute any installation pages, preference pages, > or install commands, but does contribute the check for updates handler. > - include a sample ini file that itemizes all of the existing update check > preferences that are currently settable through the pref ui > - define prefs for additional policy control (repo visibility, drill down in > the update wizard, license management) This is done. The bundle org.eclipse.equinox.p2.examples.rcp.cloud now serves this purpose. This example has been updated to define preferences that map to all of the configurable Policy items. The example includes a plugin_customization.ini file that can drive these preferences, as well as examples of show the p2.ui.sdk.scheduler preferences can also be manipulated. It is not a "bolt-on" feature (yet), but that would not be too difficult to do following this example. The things that would be needed to turn this into a bolt-on feature: - bug 311475 would be needed to control whether branded update notification was used - this example still includes an install and an update handler (and can upgrade so that install is replaced with discovery). We might want to come up with a way for the application to specify what kind of install (if any) is desired. For example, some preference that would map install to either open a discovery UI or the install wizard. The trick is how to control the menu contributions (we don't want to include an install menu item if no install at all is desired.) I will add these items to bug 281226. Fixed in HEAD >20100503.
(In reply to comment #5) > We might want to come up with a > way for the application to specify what kind of install (if any) is desired. > For example, some preference that would map install to either open a discovery > UI or the install wizard. The trick is how to control the menu contributions > (we don't want to include an install menu item if no install at all is > desired.) > > I will add these items to bug 281226. - While summarizing the state of things in that bug, I realize that the bolt-in feature should just be update only. There are still issues with respect to UI contributions (for example, should the installation history and installed software pages be shown?) - if install is desired, then the discovery feature can be added also. - if the SDK install wizard is desired, we'd need an install feature for that, but honestly in most RCP cases I would think the discovery install experience would be preferred.
