Bugzilla – Full Text Bug Listing
| Summary: | p2 should register bundle groups | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | DuWayne Morris <dmorris> | ||||||||
| Component: | p2 | Assignee: | P2 Inbox <equinox.p2-inbox> | ||||||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||||||
| Severity: | normal | ||||||||||
| Priority: | P3 | CC: | jcayne, jkubasta, john.arthorne, pascal, tjwatson, xubing | ||||||||
| Version: | 3.4 | ||||||||||
| Target Milestone: | --- | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Windows XP | ||||||||||
| Whiteboard: | stalebug | ||||||||||
| Bug Depends on: | |||||||||||
| Bug Blocks: | 222382, 241545, 361454 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
DuWayne Morris
adding to cc list. This defect is blocking a fix for 222382, marking as blocker. Does this work if you have the org.eclipse.update.configurator bundle in your configuration and started? Given where I am and I want to fix this today if possible as a work-around, how do I use the API's to grab the bundle and start it such the the service will be there when we make the getBundleGroupProviders() call? You could try something like this to see if it works.
Bundle b = Platform.getBundle("org.eclipse.update.configurator");
if (b != null)
b.start();
That was simple and worked, thanks! (In reply to comment #5) > You could try something like this to see if it works. > > Bundle b = Platform.getBundle("org.eclipse.update.configurator"); > if (b != null) > b.start(); > I suggest you transiently start the configurator bundle. Otherwise the bundle will be marked as persistently started Bundle b = Platform.getBundle("org.eclipse.update.configurator"); if (b != null) b.start(Bundle.START_TRANSIENT); Otherwise I know I will get a bug future bug report asking why update.configurator is always starting persistently on restart :) Pascal mentioned that it is likely similar to the fixed problem with "Tip and tricks" menus - nobody starts the update configurator bundle. DuWayne, does this solution work for you? Although this is a change from 3.3, it isn't really a bug. The Platform.getBundleGroupProviders() API states, "Returns the currently registered bundle group providers". In this case the bundle group provider implementation you want is org.eclipse.update.configurator. If that bundle is not started its service implementation is not available, as expected under the OSGi services model. Yes, this fix is working, and I appreciate the rather immediate help on this. I would offer the following comments: 1. When I start eclipse UI, this service is started automatically with the same bundleGroupProvider. 2. The documentation I read said that the bundle group provider API would function if Platform.isRunning() returns true, which is the case. 3. It is not at all obvious that starting an application that exists within the eclipse install (in this case in package org.eclipse.hyades.execution) does not cause services registered in the install to be available. So, since the bundle group provider exists and is registered in the install I am starting, I would think it should be started. There may be some fine points here that I am missing, but the behavior to myself and others in the TPTP Platform project was confusing and it was difficult to identify the nature of the problem. Given all the above, does it remain the case that you believe this is working as designed? Given that the bundle group providers are coming as OSGi services, then the behavior you are seeing is expected, in a sense that the services are not registered until the bundle registering those is active (this is as per OSGi specification). Now the key difference between 3.3 and 3.4 is that in 3.3 update configurator was always started because it was the part that was installing bundles into the system. In 3.4 that has changed and it is now a variety of other bundles that provide the same behavior. Lowering severity since we have a workaround allowing TPTP to progress. Now since we are talking about bundle group, and by curiosity, what are you trying to achieve when getting the bundle groups? Thanks for the comments. The downgrade of severity is appropriate, since we have a work-around. I think this is a worthwhile discussion of this issues. In TPTP, we are making this call to gather configuration information needed to run the Integrated Agent Controller (IAC). The issue that was really confusing was that when this call failed, I found there was a HashMap in Eclipse core of 33 classes of services running, and only this one seemed to be missing even though the service objects clearly indicated I was running an instance of the workbench. I would agree with your comments if the API was named getActiveBundleGroupProviders() or if there was a separate API to get a list of BundleGroupProvider names and start them if needed. Moreover, I believe it is wrong to hard-code the names of eclipse services in TPTP that might change in the future. Further, I don't believe I should need to know the names of installed bundle group providers. If I have called this Platform API, it is obvious that I wish to gather configuration data. Returning an empty list is not providing a service. I would suggest that if this API is called, Eclipse should start the installed services and return that list, or provide an API that does start them, or at least provide an API that returns a list of the service names so they can be started. The notion of not starting these services if they are not needed is appropriate and good, it saves time and resources. However, I believe functionality to get the list and/or activate the bundle group services is necessary and that the provided work-around is not a good permanent solution. All of the above assumes that Platform.isRunning() returns true. *** Bug 247352 has been marked as a duplicate of this bug. *** The workaround does not appear to work anymore. Using the example below based on bug 242621, the IBundleGroupProvider.getBundleGroups() is not returning the BundleGroup in order to obtain the installed bundles. Is there an alternate way we should obtain the installed bundles using p2? Steps to reproduce: 1. Download and extract the Eclipse 3.5.2 p2 installer to C:\p2installer\eclipse. Optionally, change the installer.properties to point to the Galileo update site. 2. Run p2installer.exe, selecting shared install and setting the install directory to C:\p2installer\eclipse. Install the Eclipse SDK. 3. Using the Eclipse SDK that was installed, create a Sample Hello World plug-in with a UI. In the action put in the workaround and call to get the Bundles. The size of the BundleGroup returned is 0. Note that there are no features in C:\p2installer\eclipse\features which is where org.eclipse.update.internal.configurator.SiteEntry.detectFeatures() looks. I could not find features in the .p2 directory. Sample code that was added to the Action.run(): IBundleGroupProvider providers[] = Platform.getBundleGroupProviders(); if (providers.length == 0){ Bundle b = Platform.getBundle("org.eclipse.update.configurator"); try{ if (b != null) b.start(Bundle.START_TRANSIENT); } catch (Exception e){ } providers = Platform.getBundleGroupProviders(); } for (int i = 0; i < providers.length; i++) { IBundleGroupProvider provider = providers[i]; IBundleGroup groups[] = provider.getBundleGroups(); System.out.println("Provider, " + provider.getName() + " has a group size of " + groups.length); for (int j = 0; j < groups.length; j++) { IBundleGroup group = groups[j]; Bundle bundles[] = group.getBundles(); for (int k = 0; k < bundles.length; k++) { Bundle bundle = bundles[k]; System.out.println(bundle.getSymbolicName()); } } } (In reply to comment #14) > The workaround does not appear to work anymore. Using the example below based > on bug 242621, the IBundleGroupProvider.getBundleGroups() is not returning the > BundleGroup in order to obtain the installed bundles. Is there an alternate way > we should obtain the installed bundles using p2? Since the features are missing on disk, this means your profile does not have the following property defined (under p2\org.eclipse.equinox.p2.engine\profileRegistry\<yourProfileId>): <property name='org.eclipse.update.install.features' value='true'/> If you set that property in your profile (I believe this can be added to the installer.properties file), then the features will be installed and the bundle group provider registered by org.eclipse.update.configurator should return the expected result. On the positive side, the workaround mentioned earlier involving manually starting bundles is no longer required. The update bundle now exposes the IBundleGroupProvider using OSGi Declarative Services, so the bundle does not need to be started in order for the service to be available. (In reply to comment #15) > Since the features are missing on disk, this means your profile does not have > the following property defined (under > p2\org.eclipse.equinox.p2.engine\profileRegistry\<yourProfileId>): > > <property name='org.eclipse.update.install.features' value='true'/> > Thanks John! I put org.eclipse.update.install.features=true in my installer.properties and it installed the features into the .p2 directory. With this setting, I also see entries in the Help -> About -> Installation Details -> Features which were not there for the previous install. > > On the positive side, the workaround mentioned earlier involving manually > starting bundles is no longer required. The update bundle now exposes the > IBundleGroupProvider using OSGi Declarative Services, so the bundle does not > need to be started in order for the service to be available. Thanks for the update on the workaround, I will look into removing the following from the code: if (providers.length == 0){ Bundle b = Platform.getBundle("org.eclipse.update.configurator"); try{ if (b != null) b.start(Bundle.START_TRANSIENT); } catch (Exception e){ } providers = Platform.getBundleGroupProviders(); } After installing with the new option I used p2 to install TPTP from the Galileo update site. The features were installed into the .p2\org.eclipse.equinox.p2.touchpoint.eclipse\features. Using the Sample plug-in and a feature, I installed the Sample plug-in into the shared installation. The getBundleGroups() returned the bundle groups including for TPTP. However when iterating through the bundle groups, the IBundleGroup.getBundles() returns nothing and has a size of 0. Using the Sample Plug-in with an Eclipse Launch configuration, returns entries for the bundles. Is there another option that needs to be set in the installer.properties? (In reply to comment #17) > Is there another option that needs to be set in the installer.properties? Not that I know of. I don't know why this isn't working for you. If this still isn't working for you, please enter a bug against Platform Update. From looking at the implementation of getBundles it seems there are a few possibilities, such as not being able to get the PackageAdmin service. You could try to set a breakpoint here (FeatureEntry.getBundle) and see why it is returning an empty list. (In reply to comment #18) > Not that I know of. I don't know why this isn't working for you. If this still > isn't working for you, please enter a bug against Platform Update. From looking > at the implementation of getBundles it seems there are a few possibilities, > such as not being able to get the PackageAdmin service. You could try to set a > breakpoint here (FeatureEntry.getBundle) and see why it is returning an empty > list. Thanks for the suggestion John, I opened bug 311387. Created attachment 205648 [details]
work in progress
Work in progress.
Notes/todo:
- need to implement IBundleGroup#getBundles
- most of the property values shown in the About dialog aren't externalized (some are... why isn't it consistent?)
- determine interaction with update.configurator, don't want to have both registered at the same time
I've been working on this and have a version working. Here are some open questions that need to be discussed: - What is the behaviour if both the update configurator and p2 are present? Currently if the update configurator bundle is around then we defer bundle group definition to it. Is there ever a case where we have both but they might return different results so we want to combine? - Currently the update configurator only returns non-source bundles which also have branding. Is this the same behaviour we want from p2 and if so, how do we do this? - The p2 version does a query on the profile's IUs and looks for IUs with the "group" property. This returns slightly different results than the update configurator one (which gets the entries from the platform.xml). Also the ids which appear in the About dialog have .feature.group on the end. My general question is why do we have this mechanism of IbundleGroup at all? Who uses it and what for? I suspect that it only is the about dialog or something like that in which case I'm wondering if we need to retain the mechanism or just make something depending on p2 directly. (In reply to comment #21) > I've been working on this and have a version working. Here are some open > questions that need to be discussed: > - What is the behaviour if both the update configurator and p2 are present? > Currently if the update configurator bundle is around then we defer bundle > group definition to it. Is there ever a case where we have both but they might > return different results so we want to combine? The only difference would be if someone had installed a group without installing the features themselves. I don't think it is important. > - Currently the update configurator only returns non-source bundles which also > have branding. Is this the same behaviour we want from p2 and if so, how do we > do this? See general question > - The p2 version does a query on the profile's IUs and looks for IUs with the > "group" property. This returns slightly different results than the update > configurator one (which gets the entries from the platform.xml). Also the ids > which appear in the About dialog have .feature.group on the end. Does it matter? (In reply to comment #22) > My general question is why do we have this mechanism of IbundleGroup at all? > Who uses it and what for? I suspect that it only is the about dialog or > something like that in which case I'm wondering if we need to retain the > mechanism or just make something depending on p2 directly. org.eclipse.rcp has no current dependency on any provisioning technology. I think this makes sense because someone building an RCP app might just want update.configurator, or even a hard-coded osgi.bundles list. IBundleGroup is only used by the splash screen AFAIK, but I think it is still useful to avoid the hard dependency on p2. > > Also the idswhich appear in the About dialog have .feature.group on the end. > Does it matter? Not a big deal, but easy enough for us to just chop that off when displaying branding information. Especially for features that already have "feature" in the name this looks really goofy to the end user (blort.feature.feature.group). Pascal, to answer your question currently the only place in the Eclipse SDK that uses BundleGroupProviders is indeed the About dialog, but they are API so we have to support them. Based on the initial comments in this bug we can safely assume there is at least one non-SDK client using these APIs. John and I talked about the registration of the providers and since we already have a System property to tell whether or not the Update Manager is the one performing the reconciliation (org.eclipse.update.reconcile) we decided to use that property to also indicate whether or not UM should register a Bundle Group Provider or to defer it to p2. This seems like a good idea and is a relatively straight forward change. There is a more difficult problem though when it comes to the implementation of the p2 bundle group provider and a backwards compatible story. Currently the bundle group provider is supplied by update manager and this is driven by the platform.xml. For each site element listed, there is a list of features which supply branding. The key thing here is the xml contains a location for each feature, so we can go to disk and load the about.ini, about.mappings, images, and any other files that we need. The problem is that if the bundle group provider is supplied by p2 and based on the IUs which are in the profile, I'm not sure we have the location of the feature on disk. It isn't in the profile and not in the bundles.info file (expected since these are features) in the config area. Any suggestions on how to get the feature location on disk? Pascal suggested we hook into the InstallFeatureAction and write out a new file in the configuration area similar to the bundles.info but with information about the features. This seems like the best solution but we need to be careful with the migration case. Consider the following: - user has 4.1 + other features installed - update manager provides About info and reads from platform.xml - user updates to 4.2 - p2 now provides About info and reads from features.info If any features were updated then they would be written out in the new file but other ones would just seem to disappear. Created attachment 209697 [details]
work in progress - p2 repo
Created attachment 209698 [details]
work in progress - update repo
I've attached some work-in-progress patches. With them, p2 registers a bundle group provider and provides info to the About screen. There are still things to do like discovery of the feature information (perhaps in a features.info file), as described in the above comment. 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. -- The automated Eclipse Genie. |