Bugzilla – Full Text Bug Listing
| Summary: | Feature branding is not displayed in About Dialog | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Kai Toedter <kai.toedter> | ||||||
| Component: | Update (deprecated - use Eclipse>Equinox>p2) | Assignee: | John Arthorne <john.arthorne> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | aniefer, d.nachev, daniel.kruegler, dj.houghton, jeffmcaffer, pascal, rscott, tjwatson | ||||||
| Version: | 3.4 | ||||||||
| Target Milestone: | 3.5 M6 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows Vista | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 241545 | ||||||||
| Attachments: |
|
||||||||
|
Description
Kai Toedter
Created attachment 106316 [details]
Sample projects that can recreate the problem
THe attached zip contains 2 project that demonstrate the problem. The first tis the basic mail plugin with branding information. The second is a feature that depends on the mail plugin and also contains a product. The mail application is setup as the branding plug-in.
I had set this up in preparation for adding a bug, but found that Kai had already posted this one.
I Also found that the same problem happens if I use p2installer to crate the installed copy instead of director. This is probably because the update.configurator bundle is not started and update.configurator is still the entity registering the entities that gets registered to fill the UI. @Pascal But then there is a mismatch between the original export and the repository created (both done by the product export wizard in a single step), since the feature branding is showing up correctly in the original export. This is "normal". The runnable application that is exported as part of the build is not a p2-enabled product (it does not have a p2 folder at the root) and therefore it does not exactly behave as the p2 enabled one. I think there is a bug about that in the PDE build bucket. To be correct, the runnable application resulting from the PDE Build export should result from a p2 director call. I found a solution (hack) for 3.4.1 to get the feature brandings back. See my blog entry at http://www.toedter.com/blog/?p=39 This may be related to bug #261331 In the product that is exported, the update.configurator bundle is marked as started in the bundles.info file in the configuration. In the repository that is exported, the update.configurator bundle is not marked as started so when we use the director to install the product in a new location, it is not marked as started in the resulting bundles.info in the configuration. This is the difference between starting the exported product and starting a product that has been provisioned by the exported repository. The features (and branding) listed in the About dialog are contributed to by IBundleGroupProviders. The activator for the update.configurator bundle is one of those providers. If the bundle doesn't get started then the bundle group provider is not registered and the branding information is not seen in the About. In Eclipse 3.4, the update.configurator bundle was NOT marked as started but by coincidence it was touched by another bundle early on and since it is marked as lazy start, it started and was able to provide a list of bundle groups when prompted. In Eclipse 3.5 (and perhaps 3.4.x?) the code which touched the update.configurator was removed and therefore the bundle doesn't get started automatically and it relies on the information in the bundles.info file. A couple of things to note: - Andrew noted that in Generator#generateBundleConfigIUs we check to see if we are dealing with the update.configurator bundle. If so, then we explicitly don't mark it as started. (this explains the difference in behaviour since the product export doesn't use the generator but the repo export does) - John mentioned that this is the sort of thing that we could use DS for. (it is being released into the SDK this week) We could declare that the update.configurator bundle provides a bundle group provider service and it wouldn't have to rely on always being started in order to see the results. *** Bug 261331 has been marked as a duplicate of this bug. *** Created attachment 126496 [details]
Patch to make update.configurator register bundle group provider via DS
This patch creates a DS component that registers the IBundleGroupProvider service even before the bundle has started. Through testing I confirmed that the update.configurator bundle only becomes active when a client obtains the IBundleGroupProvider service.
Fix released to HEAD. For future reference, in case this code pattern is copied elsewhere: I was missing the check to only register the service if not already registered by DS. See patch in bug 268150. |