Bugzilla – Full Text Bug Listing
| Summary: | core.runtime missing start level when platform feature not included | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Andrew Niefer <aniefer> |
| Component: | p2 | Assignee: | P2 Inbox <equinox.p2-inbox> |
| Status: | RESOLVED INVALID | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | richard.gronback |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Andrew Niefer
I'm not convinced there is really a bug here in p2, the explanation I have is as follows: 1) The org.eclipse.jdt feature does not include org.eclipse.platform, it requires it. 2) Metadata generation is performed on those bundles assembled/packaged by PDE/Build. 3) PDE/Build only assembles/packages included features, not required features. Therefore, in absence of another feature including org.eclipse.platform (in your case the generated container feature when you add it to the .product file), none of the bundles under org.eclipse.platform will get metadata generated for them. The resulting metadata repo, by itself, does not contain enough IUs to actually install the product. Your director calls were likely only working by virtue of bug 241430, where the director is also considering repos known in the preferences (eclipse ships with Ganymede repos prepopulated in the preferences: configuration/.settings/org.eclipse.equinox.p2.*.prefs) In this case, the director is then finding the required IUs on the galileo site and using them. However, configuration IUs which set the start levels are required by the product IU and the dsltk product IU does not require them (because of 1,2,3 above). Therefore, the install can pick up the missing IUs, but doesn't get any special configuration for them. If there are any suggestions as to what p2 or PDE/Build can do to help in this situation, I can consider them. Otherwise we can close this as invalid. (I am getting releases mixed up, obviously paragraph 5 above refers to Ganymede, not Galileo). It may very well be invalid. But first, what is the last argument do, and when would having it false for org.eclipse.core.runtime be a valid condition? False means don't start the bundle. This is the default for all bundles that don't have start level information explicitly associated with them. It is set by the "tooling.osgi.bundle.default" IU that is required by your product IU. Most such bundles (including org.eclipse.core.runtime) are marked as Bundle-ActivationPolicy: lazy. Meaning they will be started the first time someone loads a class from them. Valid configurations where org.eclipse.core.runtime would not be started would include configurations that are more "equinox" as opposed to "eclipse". - Configurations that don't use the default ApplicationLauncher service setup. They may run without an application and be more of a server than can install/uninstall and start and stop applications on demand. - Configurations that don't use the eclipse registry for application discovery and instead register ParameterizedRunnable services directly. - And generally, applications that don't use the eclipse registry at all and just use osgi services. I did find a problem here in pde/build and I raised bug 249411. FWIW, I have new product configuration that includes org.eclipse.sdk, which includes org.eclipse.platform and the bundles.info entry was generated like this using 3.5M1: org.eclipse.core.runtime,3.4.100.v20080714,file:plugins/org.eclipse.core.runtime_3.4.100.v20080714.jar,4,false |