Community
Participate
Working Groups
Bug 159122 and bug 107738 are about moving startup.jar into the plug-ins directory. The new name will be org.eclipse.equinox.startup. This jar will also provide support for the new splash screen story (bug 154088). When this move happens, PDE/UI should prefer to use the equinox.startup jar from the plugins directory over the old startup.jar in the root. (Note that there is currently an org.eclipse.equinox.startup in the equinox-incubator as part of the work for the splash screen)
We need to understand and itemize the ramifications on the PDE side. 1. The classpath when launching Eclipse applications and Plug-in JUnit tests will certainly be affected. Did the code just move locations (ie. to org.eclipse.equinox.startup) or did the fully-qualified name of the Main class also change? is it still called org.eclipse.core.launcher.Main? 2. When showing the splash screen, do I need to pass in different arguments now? 3. When creating RCP product, we currently copy startup.jar from the root. What do we do now?
1) As of right now, the code has just moved locations. It is still called org.eclipse.core.launcher.Main. We were considering renaming it to org.eclipse.equinox.launcher.Main but have not yet done so. Is it better to keep the name the same? Do we gain anything by renaming it? 2) Since the splash screen is now in the same process, it no longer has a timeout in the native code. We should remove the timeout and change that argument to simply be "-showsplash". The launcher has been separated into (for example) eclipse.exe and eclipse_<version>.dll. When starting from Java, the splash screen is shown by loading this library in Java and calling a native method. The new startup jar is currently finding this dll by looking for it in the install location. The new startup never spawns a new process so the current -launcher argument is no longer strictly necessary. We could consider changing this argument to point to the shared library instead. (Or add a new argument -launcherLibrary). 3) We should copy one from the plugins directory. The startup jar is now technically a bundle and should be resolved, so we should prefer that one. Export will also need to copy the launcher library beside the executable. (Note that both the library and the startup jar will now be versioned and in theory updateable. We will either need to use the highest version one, or which ever one is being used by the current eclipse). One question is: When branding the launcher with a name ie Product.exe, should we also rename the library (ie product_<version>.dll)? Things would be simpler to have it always named eclipse. (When not specified, both the launcher and startup jar need to look for the library to use). PDE.Build will also need to handle this.
After a discussion with Jeff & Pascal, this is what we are proposing for the new shape of things: The startup.jar becomes a bundle, org.eclipse.equinox.launcher. The package name is changed to match: org.eclipse.equinox.launcher.Main. The native executable is in the root as before, the native launcher libraries are in fragments (ie org.eclipse.equinox.launcher.win32.win32.x86) in folder form. eclipse/ - eclipse.exe - plugins/ - org.eclipse.equinox.launcher_1.0.0.v2006.jar - org.eclipse.equinox.launcher.win32.win32.x86_1.0.0.v2006 - eclipse.dll - META-INF/manifest.mf eclipse.exe will accept a -library argument indicating the folder containing the library or the library itself. If this argument is not specified, it will look in the plugins directory for the fragment. Similarily the startup jar (now org.eclipse.equinox.launcher) will use the library specified with -library, otherwise it will use the library in the fragment co-located with it. To match current behaviour, the splash screen will be displayed simply by passing a single argument "-showsplash". (This is dependent on the startup jar being able to find the library). For export, the startup jar and the libary are now bundles, just include the bundle and appropriate fragment from the state. (or if they aren't there, check the state of the running eclipse). We don't have to worry about branding of the library since it is in a fragment. It can just be called eclipse.dll (or eclipse.so).
(In reply to comment #3) > Similarily the startup jar (now org.eclipse.equinox.launcher) will use the > library specified with -library, otherwise it will use the library in the > fragment co-located with it. Question: should the library filename be version numbered as well? The SWT folks seem to use a simple version numbering scheme. I think that that is to support distinction of the libs when used outside of Eclipse > To match current behaviour, the splash screen will be displayed simply by > passing a single argument "-showsplash". (This is dependent on the startup jar > being able to find the library). for compatibility are we going to just ignore any timeout arg that might be on -showsplash? > We don't have to worry about branding of the library since it is in a fragment. > It can just be called eclipse.dll (or eclipse.so). Since we have rejigged things a bit, would it make sense to rename eclipse.dll to be launcher.dll since it is in the launcher fragment?
(In reply to comment #4) > Question: should the library filename be version numbered as well? The SWT > folks seem to use a simple version numbering scheme. I think that that is to > support distinction of the libs when used outside of Eclipse The original idea was to version the library in the same manner as SWT. This becomes slightly redundant when it is placed in a fragment, so the launcher code could be simplified slightly if it wasn't versioned. I guess the question is whether we expect people to take this library and use it outside the context of the fragment. If so, then we should probably version it. > > > To match current behaviour, the splash screen will be displayed simply by > > passing a single argument "-showsplash". (This is dependent on the startup jar > > being able to find the library). > > for compatibility are we going to just ignore any timeout arg that might be on > -showsplash? We could, it would be a special case in the argument parsing, but it would mean that PDE/UI would not necessarily need to make changes here. > > > We don't have to worry about branding of the library since it is in a fragment. > > It can just be called eclipse.dll (or eclipse.so). > > Since we have rejigged things a bit, would it make sense to rename eclipse.dll > to be launcher.dll since it is in the launcher fragment? > Makes sense to me.
(In reply to comment #5) > The original idea was to version the library in the same manner as SWT. This > becomes slightly redundant when it is placed in a fragment, so the launcher > code could be simplified slightly if it wasn't versioned. I guess the question > is whether we expect people to take this library and use it outside the context > of the fragment. If so, then we should probably version it. dunno. For now lets not version it (simple approach) and see if the need arises. > > for compatibility are we going to just ignore any timeout arg that might be on > > -showsplash? > We could, it would be a special case in the argument parsing, but it would mean > that PDE/UI would not necessarily need to make changes here. Is it just PDE that is at issue here? What about other people who have scripts, shortcuts, ... that launch? I typed that and then I questioned, how many such people would be spec'ing -showSplash? dunno the answer here. Suppose we could take the simple (no special case) approach first and see how it works.
will close this one. outstanding issues regarding the product file and exporting will be captured in bug 168616
