Community
Participate
Working Groups
When building products for which the .product file does not specify start level information, build should generate default start level information in the same way it has always done for the config.ini/bundles.info. This generation should take the form of p2.inf advice beside the .product file. See bug 265217
Now that Simon has committed Bug 265217, should we try and create a p2.inf file for the RCP feature, and use that to start the proper bundles? We have to consider the case when there is more than 1 CU for a given host (Bug 264730. I can start on that one tomorrow.
I have made these changes. If a .product has no accompanying p2.inf and the .product does not specify any start information, then we generate a default p2.inf. We generate CUs for any of the following which are in the set of bundles being built: org.eclipse.equinox.simpleconfigurator (start at level 1) org.eclipse.equinox.common (start at level 2) org.eclipse.osgi (start at -1) org.eclipse.core.runtime (start at level 4) org.eclipse.equinox.ds (start at level 1) org.eclipse.equinox.launcher (-startup) org.eclipse.equinox.launcher.* (--launcher.library) org.eclipse.update.configurator (start at level 4, see bug 235179 also set org.eclipse.update.reconcile=false) I will think about adding org.eclipse.equinox.p2.reconciler.dropins to this list. I also added a property "org.eclipse.pde.build.default=true" to every CU we generate. I suggest using this to give priority to others when we find more than 1 CU, this is the easiest way I could think of to deal with some nested feature also providing CUs for these same bundles.
