Community
Participate
Working Groups
If you create a product and set some bundles to start (with start level default), when you export and then try to run, the product won't launch. It says "Start level of 0 is not valid".
Is this a publisher or PDE bug?
I assume that we have "0" in the product file and this should be translated to "default" when you export and publish.
is "default" an acceptable start level? In the launch configurations you can choose what you want default to be. if default is acceptable, i'm happy to write out the string "default" in the publisher.
default isn't an acceptable start level, 0 isn't either. The publisher needs to write out the default start level if it's "0", which is based on the osgi.defaultStartLevel property and that in the Eclipse land is generally "4"
This should be fixed before M7 imho
Should I just hardcode 4, or is there a place I query to get the default?
it should be a property, osgi.defaultStartLevel
It looks like this property is not set by default. So I will check this first, but if I don't find anything I'm going to have to hard code '4'. I have a patch ready, but it will conflict with Bug 273747.
Created attachment 133598 [details] Sets a default start level if we find 0 in the .product file This patch sets a default start level if we find 0 in the .product file. The patch first looks at osgi.defaultStartLevel and if this property is not set, we use 4. I don't have tests in this patch because the patch will conflict with bug 273747. After that patch goes in, I can add some test cases here.
Andrew, John, this needs to make M7 :)
I just ran across this (see my comment on bug 269111) in I20090428-0100. I can't tell from the comments/patch if you are proposing to insert the default start level (4) onto every bundle listed in osgi.bundles that currently has a "@0:start". I don't believe this would be the correct approach (and my apologies if I'm misreading the comments here). Instead, bundles configured for the default start level should have no start level (just "@start"), in which case they will inherit the value of the osgi.bundles.defaultStartLevel property at runtime. This is the behavior used when launching products from within the workbench today.
The patch does what is suggested in Comment #4 it writes out the value of osgi.defaultStartLevel if the value is set to '0' (or 4 if defaultStartLevel is not set). Chris, was this not the desired behaviour. Should I just write out: @start. Please advise, and I can fix the patch.
@0:start should translate to @start
FWIW, I haven't seen any issues with the "osgi.defaultStartLevel" property not being populated correctly in exported config.ini files... it's just the tags on the bundles that's causing the failure on launch.
Created attachment 133824 [details] Updated patch This patch now writes out nothing if 0 is set. I think the confusion here is that I assumed osgi.defaultStartLevel controlled the publisher, but I think this property is meant for the provisioned system. Let me test this patch before it's releaesd.
Updated patch is better, the original was not quite right because it was using the default start level of the running eclipse. It really needed to use the default level of the product we are configuring. The new patch just sidesteps the whole issue.
Ok, I have tested this out, and it does the right thing. When installed, we get the proper start levels, and the metadata looks correct too.
done
Should this fix be in M7 and/or I20090503-2055? I'm still seeing "@0:start" in exported product config.ini files with both versions. I did update my target with the M7 delta-pack and equinox bundles.
Are you using a custom config.ini? Are you building a feature based or plug-in based product? I just tried this out with I20090430-2300 and it seems to work, but maybe my setup is slightly different from yours. I'm re-opening since this is obviously very important.
Thanks for reopening, Ian. I'm not using a custom config.ini. I'm using the default values for a new product file, so it's a plugin-based product. One thing I should mention - this is a bundle line-up that does not include simpleconfigurator, so I'm looking at the osgi.bundles property in config.ini. If I add simpleconfigurator (and prereqs) to my line-up, then bundles.list does get populated correctly and the product runs just fine. To reproduce: 1. New workspace 2. Configured my target to point to only 3.5M7 equinox-sdk and delta-pack bundles. 3. New generic project containing new product file. 4. Leave Product and Application values unset. 5. On Dependencies tab, add org.eclipse.equinox.http bundle, Add Required Plug-ins,should have 5 in the list. 6. On Configuration tab, add http bundle. Set auto-start to true (see **** below) 7. On Launching tab, add "-console" to Program Arguments, add "-Dosgi.noShutdown=true -Declipse.ignoreApp=true" to VM args. Also used "Bug273961" as the launcher name. 8. Export product (I have "sync" and "generate metadata" turned off), resulting config.ini has "@0:start" values for http bundle. *** I just reported bug 274889, which prevented me from changing the auto-start value via the editor. Please update that bug if you can or can't reproduce this issue too. If you do run into the same issue, just open the .product file as a text file and change the start level there. I get the same results with an existing product file that has several bundles enabled for auto-start at default start level. I will also attach my product file here for reference. If you want me to post a quick screencast running thru the scenario on my computer, I'd be happy to do that.
Created attachment 134310 [details] Product file to reproduce
(In reply to comment #21) > 8. Export product (I have "sync" and "generate metadata" turned off), resulting > config.ini has "@0:start" values for http bundle. > The publisher is not involved if "generate metadata" is turned off. This is a different problem than the original, I would prefer to open a new bug rather than re-use this one. See bug 274901 Note the general cause of this is that both build and p2 code had been using -1 as the value for default, UI setting the default as 0 screws us up.
*** Bug 276376 has been marked as a duplicate of this bug. ***
