Community
Participate
Working Groups
Build Identifier: 3.6.0 and 3.6.1 When defining a custom splash screen using a plugin containing splash.bmp and a reference in the eclipse.ini file (gets written using p2.inf), the custom splash screen only shows on 32bit win32 and 32bit linux. On all 64bit (osx, win7, linux) the custom splash screen does not show up. The custom splash screen in the attached example is derived from splash.bmp delivered as part of the 64bit linux Eclipse SDK. The entries written into the eclipse.ini file are written under all OS and the plugin containing the image is always there (unpacked). The following touch point is used to add the splash configuration: instructions.configure=addProgramArg(programArg:-showsplash);addProgramArg(programArg:ch.netcetera.splash.demo); The resulting entry in eclipse.ini looks like that (under all tested OS): -showsplash ch.netcetera.splash.demo There are no log outputs regarding the splash screen under any OS. Tested OS: - Windows XP 32bit (ok) - Windows Vista 32 Bit (ok) - Windows 7 64bit (nok) - Linux gtk2 32bit (ok) - Linux gtk2 64bit (nok) - OS X Snow Leopard 64bit (nok) Reproducible: Always Steps to Reproduce: Repeat the following under win32, win64, linux32, linux64 and osx64 (I don't have access to a os x 32, so I cannot tell what happes): 1. install the feature from the attached demo project into an Eclipse SDK (3.6.1) 2. check that the -showsplash entry was written into eclipse.ini (p2 touch point magic) 3. check that the plugin ch.netcetera.splash.demo is present in ./plugins, that it is unpacked and that it contains the file splash.bmp 4. now start eclipse > win32, linux32: custom splash shows up > win64, linux64, osx64: standard splash shows up
Created attachment 181760 [details] Demo project containing a plugin, feature and update site that expose the issue This archive contains three Eclipse projects: - plugin project containing splash.bmp and p2.info to modify eclipse.ini - feature containing the plugin (unpack option activated) - update site containing the feature
Created attachment 181761 [details] example eclipse.ini file after the installation (taken form Linux 64bit) This is an example of an eclipse.ini file as it looks like after the demo project got installed into a newly unarchived Eclipse SDK 3.6.1. This example was taken from a 64bit Linux version.
(In reply to comment #2) > Created an attachment (id=181761) [details] > example eclipse.ini file after the installation (taken form Linux 64bit) > > This is an example of an eclipse.ini file as it looks like after the demo > project got installed into a newly unarchived Eclipse SDK 3.6.1. This example > was taken from a 64bit Linux version. I notice two -showplash entries: -showsplash org.eclipse.platform ... -showsplash ch.netcetera.splash.demo Is it like that on the 32-bit systems also? What happens if you remove the first -showsplash org.eclipse.platform entry?
This appears to be related to JNI launching vs forked java process launching. In addition to -showsplash in the eclipse.ini try also adding osgi.splashPath in the config.ini. -showsplash is consumed by the native code to display the splash screen before starting java. osgi.splashPath is consumed by the java code to display the splash screen after java is started. If the native code does not do the splash screen, then the -showsplash argument does not make its way through to java, and then Main just consults osgi.splashPath. If java is being forked in a separate process, then the splash screen can't be displayed initially by the launcher and must be displayed by Main (which looks at osgi.splashPath). Linux.x86_64 defaults to a forked java, windows defaults to JNI, but I expect this was probably tested with -vm pointed a 64bit java.exe (which forks, point to jvm.dll to use JNI). I would have expect mac to always be using JNI, not sure why it doesnt work there. One possible change here to make this more straightforward would be for the launcher to look for the splash screen even if it wasn't going to display it because java is being forked and then pass the path into java.
*** This bug has been marked as a duplicate of bug 327152 ***
