Community
Participate
Working Groups
Build Identifier: M20090917-0800 I have been trying for many days to get our product to work properly with software updates. It has been a very painful process. I won't list all of the problems here (can't get software update to work with plugin products, or Eclipse 3.6.0). With a feature product, and using Eclipse 3.5.1 I finally managed to get the Install Software wizard to appear, but it was missing a way for the user to add update sites. After a whole day reading about p2 I finally found a fix, which is to add the following the the startup() method of my UI plugin: Policy policy = new SDKPolicy(); context.registerService(Policy.class.getName(), policy, null); I'm not even sure if this is what I was meant to do all along, or if this is just a workaround, but I think the latter. The problem is that SURELY the default should be for users to be able to add update sites. And it seems wrong that I had to find out about the SDKPolicy, which isn't mentioned in any documentation (I had to go through the code). I found the wiki page http://wiki.eclipse.org/Equinox/p2/Adding_Self_Update_to_an_RCP_Application-3.5. This explains how to set your own policy. But it is interesting that it explains this in terms of how to stop the users adding repositories (update sites). This suggests that the ability to add repositories should be the default. I notice that the content of this wiki page made it into the help system for 3.6.0 (I am using Eclipse 3.5.1) Note that unlike the examples given in the help system, my product is NOT an RCP app but an IDE, a feature product using the application org.eclipse.ui.ide.workbench. Surely SDKPolicy should be the default if this is specified? It is quite possible that I am doing something wrong somewhere, but if so it is not obvious and not well documented as far as I can see. Reproducible: Always Steps to Reproduce: 1. Create a feature product 2. Build it (either through the export product wizard, or do a headless build) with p2.gathering=true (or Generate metadata checked in the wizard) 3. Run it and go to Help > Install Software....
Inexplicably, since posting this bug, even this fix has stopped working. Now, whether the product is exported using the export product wizard, or built as a headless build, the Install Software dialog does not allow the user to add repositories. The code to install the SDKPolicy is still there. I cannot explain this at all. I am completely out of ideas as how to fix this, and no-one has replied to my posts on any of the forum. Therefore I have no choice but to give up on having software updates working for our product. It will have to be released without it.
I have confirmed that the SDKPolicy is indeed installed with the following code: ServiceReference sref = getDefault().getBundle().getBundleContext().getServiceReference(Policy.class.getName()); Object service = null; if (sref != null) { service = getDefault().getBundle().getBundleContext().getService(sref); } MessageDialog.openInformation(SWTUtil.getShell(), "POLICY", "Policy is " + service == null ? null : service.getClass().getName()); Perhaps it is installed for the wrong bundle context, although that doesn't explain why it used to work. SDKPolicy definitely sets a repository manipulator, so I would expect the createRepoArea() method of AvailableIUsPage to show the repository area, as the test is if (policy.getRepositoryManipulator() != null) I am at a loss to understand why this is not working. I am sorry to create a bug if this is all just my stupidity, but it seems to me that if a user exports a product - not an RCP product, an IDE product with application org.eclipse.ui.ide.workbench, the software updates should just work, without hours (days in my case) of research on p2 and OSGi being necessary.
I have discovered that this is do with the config.ini. I was specifying my own. If I don't do that (and therefore select the radio button labelled 'Generate a default config.ini file' in the Configuration tab of the product configuration editor, it works fine. I specify my own config.ini as I want the default workspace location to be within the users home directory (osgi.instance.area.default=@user.home/workspace). Strangely, if I specify the config.ini to use to be the same as the generated one, with this extra line, I get the following error: java.lang.IllegalStateException: Unable to acquire application service. Ensure that the org.eclipse.core.runtime bundle is resolved and started (see config.ini). at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:74) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:368) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:559) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514) at org.eclipse.equinox.launcher.Main.run(Main.java:1311)
I finally managed to get software updates working correctly, and the default workspace location set as I wished, by adding the following to the product configuration file: <configurations> <property name="osgi.instance.area.default" value="@user.home/workspace"/> </configurations> Note: I was having problems with this, as it is not supported by the UI of the product configuration editor, which actually deletes these values, I created a bug for this (bug 327349), but this was quickly marked as a duplicate of bug 260328. Reading that bug, I notice this is fixed in Eclipse 3.7. But that still leaves me not entirely satisfied. Why does specifying my own config.ini as being the generated one from where 'Generate a default config.ini' is set, with the additional property above not work?
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.
This bug was marked as stalebug a while ago. Marking as wontfix. If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard tag.
