Bugzilla – Full Text Bug Listing
| Summary: | Problem displaying splash screen in 3.0 M7 | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Darrell Loverin <dloverin> |
| Component: | Update (deprecated - use Eclipse>Equinox>p2) | Assignee: | Dorian Birsan <birsan> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | birsan, jed.anderson, jeffmcaffer, john.ruud, n.a.edgar |
| Version: | 3.0 | ||
| Target Milestone: | 3.0 M8 | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Whiteboard: | |||
|
Description
Darrell Loverin
To have osgi.splashLocation or the osgi.splashPath working the first time, it requires that you ship your application with a configuration folder (former .config) containing the config.ini. The splash is found according to the system properties found in config.ini. An update agent installing a new "product" is able to update the config.ini to have include the apporpriate property setting. If you want to spec it you can: - update teh config.ini you ship with - use -Dosgi.splashPath on the command line as a VM arg Like the original poster we had the splash screen working in 2.1 but it’s no longer showing up in 3.0 M7. The welcome page and window icon of my primary feature are displayed, but my feature’s default perspective is also no longer showing up at startup. Furthermore, launching eclipse using –feature myfeatureid has no apparent effect. Converting the plugins to and from 3.0 format doesn’t seem to make any difference. I understand the need to deploy install.ini specifying our primary feature, but wouldn’t it be possible for the .config directory to be created by the platform based on information defined by the primary feature, as must have been the case in 2.1? (Possibly related: my primary feature’s default perspective is not showing up by default, as mentioned earlier). The update/install component of Eclipse is one example of an "update agent" or "configurator". It is the component of Eclipse that defines the notion of features and how they work. This division of work between update and the runtime is new for 3.0 and is still in flux. It could be that something is falling through the cracks here. Adding Dorian to the CC list... Just for a context, the splash screen is about the first thing that we do when starting eclipse. At that point OSGi or the runtime are not even started yet let alone Update. Furthermore, the Update component is optional so we cannot rely on it to tell us where the splash is (based on a choice of feature). moving to update The install.ini is used to define the default primary feature id and the default application. This file will soon be deprecated, and the values moved to eclipse/configuration/config.ini as eclipse.product (for primary feature id) eclipse.application (for application id) As Jeff described, the splash is controlled by the osgi.splashPath property in the same config.ini file. If you don't want to modify the config.ini, all these properties can be passed to the VM using the standard java system properties (-Dosgi.splashPath=..., etc.) I am closing the bug, but if you have any issues please comment and re-open. Defining osgi.splashPath in config.ini works well now that the file is shipped with eclipse, and not created at startup. However, setting feature.default.id in install.ini, eclipse.product in config.ini, and/or passing in my feature id to eclipse using the –product or – feature arguments don’t bring up my feature plugin’s perspective at startup, like it used to in 2.1. I just retested this using the latest build (20040320). My perspective is showing up when using the –perspective argument, but unfortunately so is the resource perspective. Is this likely a bug, or are there any working examples where the default product’s perspective is replaced? BTW, this is what used to happen when my app was launched using runtime-workbench, but not when launched from the command line. The default perspective is controlled by the Workbench UI and there some work in progress in that area, to do with IBundleGroupProvider/IProduct support. I cc:ed Nick, as he may have more details on this. |