Community
Participate
Working Groups
Due to the introduction of org.eclipse.core.commands in the ui stack, the confi.ini shipped with the browser example is incorrect.
I assume you mean the various platform-specific config.ini's in project source. Or do you mean the built binary one (which only works against 3.0[.1]). Any suggestions for reducing this to a single cross-platform config.ini (without use of o.e.update.configurator)? Now that bundle manifests can have platform-specific filters, could we just list all SWT fragments?
I'm considering just providing a product definition file, and deleting the .ini files.
Unfortunately, that has the same problem of having to list all the platform-specific fragments, so apparently I'd still need a different file for each platform. The browser example doesn't currently use features. Maybe it should. But I'd still like it to be able to run without update.configurator.
One possibility would be for you to list all the fragments in the .product file, and when PDE is building the product and generating the (default, not custom) config.ini file for you, we only list the fragments that match your current environment.
So PDE processes the Eclipse-PlatformFilter attributes in the manifest as well as the runtime? Will try.
We certainly pass the plugins through the platform filter before we build them. However, if you have a custom config.ini file, we leave it untouched. Also, when we generate the default config.ini, I think we still put everything on the osgi.bundles line. In any event, I think it's best to let PDE take care of you in this situation. If there is tweaking that needs to be done, we'll do it.
OK. I can't actually export right now due to bug 89663, but will try when that's fixed.
I've added a Browser.product file and deleted the other config.ini files.
Created attachment 19470 [details] Browser.product file Wassim, could you scan this, and let me know if you think it looks OK? I'm including all SWT fragments in it.
It looks good, and as requested, please do not include a custom config.ini anymore. At minimum, I will make sure that: if you are exporting to a particular ws-os-arch combination, I don't include the extraneous fragments in the config.ini Luxury: if we have time to support simultaneous multiple platform exports (in the presence of the delta pack), that the list of plugins is adjust per os-ws-arch run.
