Community
Participate
Working Groups
build i0428-0100, linux-gtk - create sample mail product - set the splash screen bundle correctly (bug 273974) - export the product (and produce a repo) - run the exported product Note splash screen is displayed ok. - run the director application, installing the product from the exported repo. - run the provisioned product Note the splash screen is not displayed.
I did this using the Prov Admin UI to perform the second install and everything worked fine for me. Is there a difference when using the director? DJ, what is missing from your provisioned app, does it have osgi.splashPath in the config.ini?
Yes, the osgi.splashPath is in the config.ini. It points to: osgi.splashPath=platform\:/base/plugins/mail All the plug-ins are in the folder: p2/org.eclipse.equinox.p2.touchpoint.eclipse/plugins/ platform:base: resolves to the OSGi install area which is not where my bundles are.
*** Bug 222260 has been marked as a duplicate of this bug. ***
The problem lies in the way we specify splash screens that is assuming a particular shape of the world (pre-p2, all colocated), and now we are trying to preserve this when everything is much more flexible. Also similar issues could occur with shared installs
As I mentioned on the duplicate, I tried this with 3.4 and we were broken there too.
*** Bug 295402 has been marked as a duplicate of this bug. ***
I suggest the best way of doing the splash screen is to have a new install action "setSplash" or something similar. This action would set the appropriate -splash argument in the eclipse.ini, and also perhaps osgi.splashPath or osgi.splashLocation in the config.ini. This is probably easiest when done a fragment IU of the bundle itself, since then we can get the artifact location on disk. Unless install actions can allow getting the installed path of arbitrary bundles, then it could go on the product.
In the most recent duplicate bug I was confused by the appearance of a new splash after cancelling an update.
In a similar variant, I actually got the wrong splash this week too. I didn't upgrade to this week's build because it had bugs, but I did get this week's splash screen. That's because I have the "download updates automatically" preference turned on, so the new org.eclipse.platform bundles from this week's builds are available on disk even though I never upgraded.
*** Bug 295568 has been marked as a duplicate of this bug. ***
The splash screen is in general broken when using a different bundle pool. A simple argument like -showsplash org.eclipse.platform Would need to be modified by p2 to resolve to a path to the highest versioned org.eclipse.platform.
Help wanted on that one. If you someone wants to do it ping and we can provide details as to where to look.
I might be able to help with this one. Could someone point me where in code the splash screen bundle is resolved? -showsplash org.eclipse.platform Also, is there an existing class that I can use to read org.eclipse.equinox.simpleconfigurator/bundles.info file?
The -showsplash argument is at least initially resolved in the native launcher, see http://git.eclipse.org/c/equinox/rt.equinox.framework.git/tree/features/org.eclipse.equinox.executable.feature/library/eclipse.c#n1353 This is because the splash screen may be displayed before the jvm is even started. The search there is as follows: 1) is the argument a file -> thats the splash bitmap 2) is the argument a folder -> use folder/splash.bmp 3) does the argument have a path separator -> look for /path/prefix_<version> and choose the highest version 4) else look for programDir/plugins/prefix_<version> and choose the highest version The programDir is generally the location of the eclipse executable. p2 probably needs to set the -showsplash with path information rather than letting the launcher resolve the argument. There is other java code in the workbench somewhere to do splash screen stuff as well.
What about osgi.splashPath in configuration/config.ini? What reads that and when? My current workaround for this issue is to replace the original value: osgi.splashPath=platform\:/base/plugins/org.eclipse.platform with a full path: osgi.splashPath=file\:/d\:/Eclipse/Sapphire/Pool/plugins/org.eclipse.platform_4.5.2.v20160212-1500/ Obviously that's brittle. Perhaps the resolution logic that interprets the original platform URI can be improved to be aware of bundle pools?
osgi.splashPath is read by the Main class in the launcher http://git.eclipse.org/c/equinox/rt.equinox.framework.git/tree/bundles/org.eclipse.equinox.launcher/src/org/eclipse/equinox/launcher/Main.java#n2250 The -showSplash argument resolved by the native code will come in and get set as osgi.splashLocation which takes precedence over the osgi.splashPath The osgi.splashPath is resolved by plain-old-java in the Main class, I forget the details of what it is resolved against, you'll have to trace through the Main.handleSplash. For completeness, the rest of the splash screen lifecycle is EclipseStarter registers a StartupMonitor service which will receive time on the primary thread as osgi starts up and the default implementation takes care of painting and ultimately tearing down the splash screen. Eventually Workbench.createSplashWrapper registers a new implementation of this service which then takes care of doing SWT progress bars and such.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
