Bug 265864

Summary:	Generate default CU advice for products
Product:	[Eclipse Project] PDE	Reporter:	Andrew Niefer <aniefer>
Component:	Build	Assignee:	pde-build-inbox <pde-build-inbox>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	irbull
Version:	3.5
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:
Bug Depends on:	265217
Bug Blocks:	241441

Description Andrew Niefer

2009-02-23 13:42:20 EST

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

Comment 1 Ian Bull

2009-02-26 01:47:25 EST

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.

Comment 2 Andrew Niefer

2009-02-27 10:58:43 EST

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.