Community
Participate
Working Groups
Build Identifier: 20100917-0705 The problem occurs when the org.eclipse.update.configurator plug-in is added to the list of plug-ins in the launch configuration. In that case, the plug-ins which have auto-start to true do not start automatically. Once this plug-in is removed from the list, the plug-ins are then started correctly. Some additional information about the problem can be found in this discussion: http://www.eclipse.org/forums/index.php?t=msg&th=208307&start=0&S=85317a1a187e4b043e28eb8a131a4916 Reproducible: Always
I was going to ask Tom for more info, but I see he commented on the forum post already. AFAIK PDE does pass the auto-start settings along to update configurator, but we do not actively test it so there could be a regression here. Is there a specific reason why you are using update configurator? Using Helios, most people either pass the bundles to start directly to osgi (no configurator) or the new simple configurator (p2). While update configurator is still available, it is not used to launch Eclipse.
(In reply to comment #1) > I was going to ask Tom for more info, but I see he commented on the forum post > already. > > AFAIK PDE does pass the auto-start settings along to update configurator, but > we do not actively test it so there could be a regression here. > If I remember correctly, I don't think update configurator has any way to auto-start bundles which are not lazy activated. I don't think this is a regression.
(In reply to comment #1) > Is there a specific reason why you are using update configurator? No, there's no specific reason for that. As I said in the discussion, the configurator plug-in is automatically added to the list of required plug-ins when the option "Include optional dependencies when computing required plug-ins" is checked. The fact is that I didn't really know what this plug-in did (I'm simply a user of Eclipse), so when I moved from Ganymede to Helios, my application suddenly didn't work anymore. It took me quite some time to figure out that the problem was in fact due to the configurator plug-in that was in the list.
There is nothing for us to do here. If you add the update configurator but not simple configurator it is assumed that you are expecting update configurator to handle startup. The auto-start settings in the launch config are set up for simple configurator. Try removing update configurator (to launch using pure osgi) or add simple configurator to your launch. Closing as WONTFIX.
Hmmm, not so sure here. I came across something similar the other day. At some point in the past I'm pretty sure that marking a bundle to be started and using update.configurator did work. This seems to be what the original poster indicates used to work. Note that it was NOT update.configurator doing the starting (don't think it ever has done that) but rather the config.ini the PDE crafted as part of the launch would have entries in the osgi.bundles list to cause the bundles to be started. What I am less clear on is whether or not you had to have a custom config.ini to make that happen or if the "generate default" option did that for you. I'm not arguing for a lot of work here but it may actually be a workflow regression.
