Community
Participate
Working Groups
Apparently, the startup.jar will cease to exist when Eclipse 3.3M5 is released. This will cause grief for headless users/develpers that have no desire to use the launcher executable. They will be forced to copy the Java launcher from a version specific directory under 'plugins'. The consequence of not having a unified Java launcher in the root is that every headless product team must create their own solution. Nick Bolt wrote a good summary of what's needed (see below). It starts with "Well it's not as bad as you'd think." and ends with concluding that a Windows user is "on his own" (no sed etc.). It's just as bad as I though :-) I'm surprised that a decision was made to remove the unified Java launcher. An increasing number of use-cases involves headless launching through Java. I would therefore humbly request that such a launcher is reinstated. This time as a very thin wrapper that does nothing more then finding and dispatching to the real launcher and that this launcher is present *before* the release of 3.3M5. Excerpt from cross-project-issues-dev... Nick Bolt writes: Well, it's not as bad as you'd think. If you're launching Eclipse from a shell script, you can just find the equinox jar and use that instead of startup.jar. cp=$(find $eclipseinstallDir -name "org.eclipse.equinox_*.jar" | sort | tail -1); /opt/java50/bin/java -cp $cp org.eclipse.equinox.launcher.Main ... If you're launching Eclipse from an ant script, you can use a mapper or simple copy/move to find the equinox jar and rename it so it's more accessible. <copy tofile="${install}/eclipse/plugins/org.eclipse.equinox.launcher.jar"> <fileset dir="${install}/eclipse/plugins" includes="**/org.eclipse.equinox.launcher_*.jar"/> </copy> <java classpath="${install}/eclipse/plugins/org.eclipse.equinox.launcher.jar" .../> If you're launching Eclipse from a cmd or bat script on Windows... well, you're on your own there. ;-)
I can explain at least part of the reason for removing the "startup.jar". Since it was not a plugin, it could never be updated with update manager. (Similarly it did not have any of the usual versioning characteristics of osgi bundles). Given that, I agree it's a bit of a pain, but not sure we want to go back to the old status quo, either. Hopefully, someone can provide more constructive suggestions than I, I just wanted to document part of the reasons, which I do agree as being desirable.
Created attachment 58716 [details] find equinox launcher jar to start eclipse w/ .cmd script Two more thoughts here, since I've already stuck my foot in this deeply. ;-) a) my hacks for running w/ shell or ant are easily ported to Windows... some googling for and a few mins of hacking on my gf's WinXPHome Thinkpad and voom. See attached. b) I agree, it sucks not being able to update startup.jar with Update Manager... but you can't update eclipse.exe either, so if startup.jar falls into the same category, what's the problem if it's nothing but a Main() call to the actual equinox jar? Doesn't seem like that would need to be updated... ever.
A couple related bugs, just to keep the threads connected: bug 170831 - JUnit tests fail to run with Eclipse 3.3 post-M4 (startup.jar has moved) bug 171756 - [org.eclipse.test] Update library.xml to new Equinox launcher?
If you really need a startup.jar then you should be able to rename the 3.3 org.eclipse.equinox.launcher jar to startup.jar and place it in the same location as the old startup.jar used to be. Copying Andrew to confirm this.
Why not just have 'startup.jar' in the plugins directory? After all, a bundle doesn't need to be named with the version (though clearly it would prevent multiple versions existing simultaneously). It seems that the issue is one of updatability and having the same named reference.
(In reply to comment #4) > If you really need a startup.jar then you should be able to rename the 3.3 > org.eclipse.equinox.launcher jar to startup.jar and place it in the same > location as the old startup.jar used to be. Copying Andrew to confirm this. > That's just the point. It's not named startup.jar, it's not in the root, and it's tagged with a version number that is likely to vary over time, thus introducing the need for sed scripts, Ant filesets with mappers, or the like. It was great before, why ruin it? (In reply to comment #5) > Why not just have 'startup.jar' in the plugins directory? > Moving it to the plugins directory will break a lot of scripts out there. IMO, a good reason to let it stay in the root. I agree with everything that's been said before. It's excellent that the launcher can be updated using the update manager. What I'm asking for is that the entry point for Java that is provided today is retained so that not every affected project is forced to come up with their own solution. I share Nick's thoughts. The eclipse.exe was split so that major functionality moved to shared objects that can be updated. Do the same with the launcher. Create a simple Java main function doing a dispatch to the real launcher and put it in a startup.jar residing in the root. No need to update that either. A related question. The old startup.jar contained a special entry point for Java Web Start. Is that present in the new launcher also?
Interestingly enough, the zip file for the M5 "test framework" distributed by the platform, does contain a startup.jar in the eclipse root ... and it appears to be a renamed equinox launcher ... now that's going to be confusing! :)
A complicating factor is that now when it is possible to update the launcher using the update manager, it's very likely that several versions will be present in the plugins directory. This will break all workarounds I've seen so far when: 1. you disable a launcher with higher version because you want to fall back to an earlier version. 2. the version numbers sort incorrectly when sorted alphabetically, i.e. 1.0.10 sorts before and 1.0.2.
Re: comment #7, we included a startup.jar to not break anyone wanting to use this version of the test framework in their builds while we work through bug 17156.
(In reply to comment #9) > Re: comment #7, we included a startup.jar to not break anyone wanting to use > this version of the test framework in their builds while we work through bug > 17156. > Thanks Sonia, for letting us know it is a temporary thing. To document it for others, I assume you meant to reference bug 171756.
(In reply to comment #9) But does the renamed plugins/org.eclipse.equinox.launcher_*.jar -> startup.jar include an org.eclipse.core.launcher.Main class? (I confess I haven't looked.) If not, then it's still going to break people since `java -jar startup.jar org.eclipse.core.launcher.Main` will get java.lang.NoClassDefFoundError: org/eclipse/core/launcher/Main. (In reply to comment #8) The scriptlets I have could be modified to sort by create date instead of by filename, so the most recent version of the equinox jar, could be selected. In the context where *I* need it (PDE-based Modeling Project builds), there's only one - I'm only unpacking a single version of an Eclipse SDK, not updating an existing install w/ UM jars. (So, really, the `sort | tail -1` is overkill.) This single-match asssumption is true for both the ant fragment and the attached .cmd script above.
(In reply to comment #4) > If you really need a startup.jar then you should be able to rename the 3.3 > org.eclipse.equinox.launcher jar to startup.jar and place it in the same > location as the old startup.jar used to be. Copying Andrew to confirm this. This should work; in fact, an early version of my hacks for library.xml (bug 171756) did just that. My concern, however, is that the class org.eclipse.core.launcher.Main inside org.eclipse.equinox.launcher_1.0.0.v20070208a.jar (from Eclipse 3.3M5) is still labelled: /* This is a TEMPORARY class to facilitate self hosting of this launcher startup jar */ which both implies that it might magically disappear one day, and that an actual solution hasn't yet been determined. For the clients that can't (or won't) jump through hoops like copying/renaming jars or running bash/ant/cmd scripts, we ought to be able to find a way to make them still work seamlessly using startup.jar and core.launcher.Main.
On the issue of "Main" ... isn't it true that the class should not have to be named by clients, if it's included in the jar's manifest as "the main" class? And, naturally, if the clients use the -jar=startup.jar type of java invocation?
(In reply to comment #12) > My concern, however, is that the class org.eclipse.core.launcher.Main inside > org.eclipse.equinox.launcher_1.0.0.v20070208a.jar (from Eclipse 3.3M5) is still > labelled: > > /* This is a TEMPORARY class to facilitate self hosting of this launcher > startup jar */ > > which both implies that it might magically disappear one day, and that an > actual solution hasn't yet been determined. Originally, keeping the org.eclipse.core.launcher.Main was a convenience thing for myself, but we have since decided that it should stay. I just haven't gotten around to updating the javadoc yet.
(In reply to comment #14) > (In reply to comment #12) > > Originally, keeping the org.eclipse.core.launcher.Main was a convenience thing > for myself, but we have since decided that it should stay. I just haven't > gotten around to updating the javadoc yet. > Well, that just begs the question then, which is the main main :) Which will be listed in the jar as the main class, and what is the difference between them?
(In reply to comment #4) > If you really need a startup.jar then you should be able to rename the 3.3 > org.eclipse.equinox.launcher jar to startup.jar and place it in the same > location as the old startup.jar used to be. Just wondering ... if somebody did that, "java -jar startup.jar" would not see any updates of Equinox Launcher which were done through Update Manager, correct? Because of that, I think I'd prefer a very thin startup.jar that just delegates to the correct Equinox Launcher. Startup.jar should have the same semantics for java, as eclipse.exe has for native -- dbl clicking it, or doing "java -jar startup.jar" should be equivalent to dbl clicking eclipse.exe.
(In reply to comment #15) > Well, that just begs the question then, which is the main main :) > Which will be listed in the jar as the main class, and what is the difference > between them? > org.eclipse.equinox.launcher.Main is the main main. It is listed as the Main-Class in the manifest. The entire contents of the org.eclipse.core.launcher.Main is : public static void main(String[] args) { org.eclipse.equinox.launcher.Main.main(args); }
(In reply to comment #16) > Just wondering ... if somebody did that, "java -jar startup.jar" would not see > any updates of Equinox Launcher which were done through Update Manager, > correct? > > Because of that, I think I'd prefer a very thin startup.jar that just delegates > to the correct Equinox Launcher. Startup.jar should have the same semantics for > java, as eclipse.exe has for native -- dbl clicking it, or doing "java -jar > startup.jar" should be equivalent to dbl clicking eclipse.exe. > If we did a thin startup.jar, all it would do would be find the launcher jar with the highest version number and call it. This is not the same as having "java -jar startup.jar" be equivalent to dbl clicking eclipse.exe. If we did that, there suddenly becomes more code in this "thin" jar, and we loose the advantage of moving to the plugins directory.
(In reply to comment #18) > If we did a thin startup.jar, all it would do would be find the launcher jar > with the highest version number and call it. I don't know exactly what else eclipse.exe does, but such a thin startup.jar sounds like a very good idea. In comment #8, Thomas Hallgren brought up the issue what happens when a specific version of the Launcher is disabled via update manager (e.g. "revert to previous configuration"). So, could a thin startup.jar also find "the highest enabled version" with reasonable effort? Or would that be overkill?
In my opinion, a "thin" startup.jar must find the *correct* version to launch. Anything else will be seriously confusing. If the the windows (or other OS) executable entry point is capable of doing that then the same functionality should be provided in the Java entry point.
For the thin startup.jar, I would say we want not so much the "correct" version, as we want the same version that the eclipse.exe would have chosen. The eclipse.exe is not capable of knowing whether the launcher bundle is enabled. (I don't want to have to start parsing the platform.xml in C). If anything other than the highest version is desired, then the eclipse.exe needs to be told which version to use with the -startup option (and perhaps also -library). Note also that the thin jar wouldn't read the eclipse.ini file, that is one of the things that the eclipse.exe does that using java -jar has never done.
(In reply to comment #21) > For the thin startup.jar, I would say we want not so much the "correct" > version, as we want the same version that the eclipse.exe would have chosen. > Fair enough. I agree that similar behavior is more important (and easier to document).
I can understand the surprise that removing the startup.jar causes, but technically speaking there is nothing that the new solution prevent to do. Could you please outline which scenarios are no longer possible, or that would not be addressed by starting by eclipse.exe?
(In reply to comment #23) > Could you please outline which scenarios are no longer possible, or that would > not be addressed by starting by eclipse.exe? Well, for one thing, there's running tests w/o loading shared libraries, as in https://bugs.eclipse.org/bugs/show_bug.cgi?id=171756#c13 https://bugs.eclipse.org/bugs/show_bug.cgi?id=171756#c20 The kicker there is that https://bugs.eclipse.org/bugs/show_bug.cgi?id=171756#c5 shows a way to run these tests w/o the need for the executable (using <java> instead), but unfortunately we're pursuing a more onerous solution. :(
In the past, starting up Eclipse through startup.jar was necessary in headless environments because eclipse.exe would pop up a dialog if the Java process it had invoked exited with an error code. There was no way to suppress the popup. That defect has apparently been fixed (with an option whose name I forget). But do we want to force users who had to invoke Eclipse through startup.jar to switch to eclipse.exe, with no transition period? How to invoke Eclipse seems like a very important part of its interface, and not something that should be changed lightly. Since startup.jar is widely used, and was necessary in certain situations, I think it should still be supported, probably as a thin wrapper. If eclipse.exe can now do everything that startup.jar could do, then startup.jar should be declared deprecated in Eclipse 3.3, and removed in the following release. That will at least give users a year to make the switch rather than focing it on them overnight.
Only a few headless invocations can use eclipse.exe because it's a windows app. As such, it doesn't provide the normal console streams (stdin, stdout, stderr), nor does it propagate the exit code. Some use cases: 1. I have several installations that use Ant. They all use java -jar to start headless invocations of Eclipse. Many of them are used with both 3.2.1 and 3.3. I'm not much in favor of changing them all and invent solutions searching for a Java launcher in order to start this Java framework. Please don't introduce an incompatibility at this basic level. 2. The Buckminster headless product is completely platform independent. Our distributions do not contain *any* executable or shared library anywhere. This is imperative to us since we do distributed builds on multiple platforms and neither the binary launchers nor SWT exists on some of them. Java is there though and the OSGi framework runs just fine. 3. I see a lot of places that needs to change when going through the Eclipse documentation. How will applications like the Eclipse standalone version of the update manager or other headless stand-alone apps that Eclipse provides be handled? 4. Consider RCP applications developed by people outside of Eclipse. My guess is that a more then just a few of them are in fact headless and rely on the unified Java startup. I was indeed surprised. Why was a decision was made to remove the only unified way to start this OSGi framework from Java? Just out of curiosity - why isn't everything written in Java (splash screen management and all) and the executable just another way to invoke the whole thing?
One use case that's not immediately obvious how to handle with the eclipse executable, is that in some tests or development environments, it's desirable to launch without the *.ini values ... to insure complete control over those types of parameters. It seems, currently, the only way to do that is to have some other way to tweak, or remove, the eclipse.ini file, instead of just passing VM parameters.
You all brought up some valid points, most of which we had carefully taken into consideration when making the decision of removing the startup.jar. Be sure that we (in fact mostly Andrew) have not spent hours on this just for the fun of it, and that the transient pain will likely be outweighed by the overall benefits that the whole platform gets. For example, it now means that startup.jar can be updated, which means that we will now be able to succesfully go from 3.3.0 to 3.3.1 and so on. Also I see the changes happening in the test framework space as goodness since we will now be running the tests in conditions even closer to the reality of the user desktop. Historically, the reason why headless applications required java, is such that they could get the proper redirection of input / output / error and this was mostly a problem on windows. Yes, it is still an issue, but the new shape we reached with this rework puts us in a better position to fix the window specific problem. In fact I have opened bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=173962 and we will try to fix it for 3.3 (I hope to use this solution for the applications shipped in the SDK). Of course this does not fix the problem of platform independent applications (like buckminster). However the process of creating an application involves repackaging eclipse in which case you have the ability to copy the launcher jar in the root of the product if this is what you decide to go with rather than giving a particular command line to your users. This last point of command line brings me back to what we consider backward compatibility. In eclipse, backward compatibility is such that one can install a plugin on top of eclipse and have it run without having to change it. However, in order to not restrict ourselves for further evolution, things like startup.jar or pde build have been evolving with less restriction because it is not seen as something that could break a customer (here customer is someone using a 3rd party plugin on top of eclipse) in the field but only breaking the development team of a product which represents a small set of people (see the pyramid of contributors in Gamma's book). Note that I'm not saying that we don't care, nor that we don't pay attention just that the impact is not as broad. David, suggested the reintroduction of a forwarding startup.jar and I do not believe this will help. This is simply because people will not have a way to notice that something is different and we are just moving in the future (the hypothetical day of the startup.jar removal) the discussion that we are having today. So in this case, "better be broken sooner than later" <g>. So all that to say that we are happy to improve the new shape of things but will unlikely reintroduce startup.jar.
>I was indeed surprised. Why was a decision was made to remove the only unified way to start this OSGi framework from Java? It is not removed, it is moved (I'm not sure what you meant by unified). It just changed name. Also note that you can also start osgi direclty by saying java -jar org.eclipse.osgi_xxxxx.jar >Just out of curiosity - why isn't everything written in Java (splash screen management and all) and the executable just another way to invoke the whole thing? Because java is just too damn slow to show up a splash screen in a timely fashion... and we have tried many tricks. Note that for me (and others around here) the exe IS just another to invoke the whole thing.
Pascal, I'm not saying that you don't care but please, PLEASE, acknowledge that this will be an issue for a lot of people out there. It's not good for Eclipse if it fails to provide a simple way to launch with Java. Java friendliness is a good thing. Using the eclipse.exe will make propagation of stdin, stdout, and stderr break on Windows. There's nothing "historical" about that. It's a matter of fact until solved. Windows is by far the biggest platform so dismissing it with being "mostly a problem on Windows" is fairly pointless. I would humbly suggest that the feasibility of the "console friendly eclipse.exe" suggested in bug 173962 is investigated thoroughly. AFAIK that is not fixable unless you introduce yet another binary launcher. You claim that it would be too restrictive for the evolution to keep the startup.jar around. I completely fail to see that argument. How can what is being proposed here (a thin startup.jar that just finds the real launcher) restrict evolution in any way? I think the opposite is more true. What you do now can easily be perceived as restricting the way Eclipse can be used. Although you indeed do have a general purpose OSGi framework, getting to the entry-point of it seems to be something that Eclipse is doing a good job of hiding. Hmm, better not use that then...
I'd just like to say, I'm all in favor of the move to improve update ability, especially for the mass of adopter-end-users who typically don't care much about exactly how something is launched, if they even know. But, I will throw out one other wild idea, in case anyone thinks it could have merit. Would it be possible to have the thin startup.jar (that's basically very very similar to the algorithm used by the executable) be distributed with only the SDK ... but not with the minimum "runtime"? (I think it is the "runtime" that what is usually used by adopter-end-user packages and products). The justification being that those that use the SDK would "know enough" to know if/when the startup.jar had to be replaced (just like they'd have to know if the executable had to be replaced). Just a thought. It just seemed like a many of the use-cases discussed had to do with more SDK like scenarios. I must say though, I'm anxious to see the "changes happening in the test framework". In fact, I'm sort of waiting for it. Is there an outlook or plan? Is there any interim advice on how to evolve test scripts, other than Nick's excellent http://wiki.eclipse.org/index.php/PDE_JUnit_Testing. Above all, no matter of exact end result, I do appreciate the improvements, and appreciate everyone's help in working together to make the transition easier, since there is a lot of downstream ripple that is costly.
Created attachment 58844 [details] Sample splash screen launcher (In reply to comment #29) > Because java is just too damn slow to show up a splash screen in a timely > fashion... and we have tried many tricks. > Just for the fun of it, I tried this example: http://www.javaworld.com/javaworld/javatips/jw-javatip104.html. It creates a splash on my screen (using a gif) before I have time to blink. What is considered a "timely fashion"? Expressed in percentage of overall startup time, what are the requirements? Sample jar attached. Try it using java -jar splash.jar. It would be great to get some timings from different platforms.
(In reply to comment #32) Thomas, the splash screen work was about more than simply displaying a graphic. We wanted to use SWT widgets in the splash screen, otherwise we would have just stayed with the old splash story (which is separate from this discussion about startup.jar). See http://wiki.eclipse.org/index.php/Equinox_Launcher_Plan http://wiki.eclipse.org/index.php/Splash_Screen_Improvements and bug 161569 for details of the investigations. Time-to-splash was a major consideration. On a cold machine (just turned on, no disk cache) the old splash method took around 6 seconds. Showing a graphic in java would have been about the same. For a properly setup eclipse using JNI to start the vm, the new launchre takes about 400ms on a cold start. (50ms on a warm start).
Andrew, thanks for the clarification. I agree that this is a side track. The real topic, the one about the startup.jar is much more important. I'll post some followup questions about the splash screen on the equinox-dev mailing list.
I have created a wiki page here: http://wiki.eclipse.org/index.php/Equinox_Startup_Issues There are classloader and security manager issues with using a thin startup.jar. Anyone using one would need to be aware of these. Because of this we are leaning towards not including a thin startup.jar in the SDK, but if someone want to write one we can make it available for download and it could probably be included in something like the releng basebuilder if the releng team desires.
Great wiki page. Very explanatory. Thanks Andrew. When reading it I thought of another IMO much simpler approach to resolve the issue: Andrew makes the following clarification in comment 21 "The eclipse.exe is not capable of knowing whether the launcher bundle is enabled". As a consequence, having more then one version of the launcher is redundant since only the highest version can be used anyway. The launcher jar is only 41k in size. So why not keep a copy of the launcher in the root (a good name could be "startup.jar") and let the update-manager update that copy whenever a new version is installed? It would be overwritten each time of course but since enable/disable doesn't work anyway, that wouldn't matter. All advantages would be there. Java invokers would not need to search for the launcher. No need for a thin dispatching launcher with class loader and security issues. Performance would be optimal. Eclipse would again be Java friendly :-) Pascal was uncertain what I meant by "Unified launcher". A term badly chosen I guess. What I mean is a launcher that is easy to find and over time keeps its name, remains in the same place, and can be invoked using same options. Just like eclipse.exe.
(In reply to comment #36) > The launcher jar is only 41k in size. So why not keep a copy of the launcher in > the root (a good name could be "startup.jar") and let the update-manager update > that copy whenever a new version is installed? It would be overwritten each > time of course but since enable/disable doesn't work anyway, that wouldn't > matter. Update is not currently capable of updating file in the root of eclipse. It does not necessarily have permission to write to that directory, as well, while running, I think that the jar might actually be locked by virtue of being opened by java.
(In reply to comment #37) > Update is not currently capable of updating file in the root of eclipse. > Implementing that would be part of the fix of course. > It does not necessarily have permission to write to that directory > It could gracefully fail in that case, informing the user of the reason. Wouldn't that be a corner case anyway? Seems to me there would be little or no point in restricting a users access to the eclipse root while permitting the same user rights to mess around in the features and plugins directory. What would be the reasons behind such a setup? > while running, I think that the jar might actually be locked by virtue of > being opened by java. > Defer the actual install to the next reboot of Eclipse (which is recommended anyway after an update). Today, the launcher looks for the latest version of the plugin. That probably takes a while since it needs to list the files in the plugins directory to do that. Let it do this instead: 1. Look for a file named startup.new. If found, rename it and overwrite startup.jar 2. Boot using startup.jar. If this fails, fall back to current behavior. I think that could be just as fast as the current approach. The update-manager creates the startup.new whenever it updates the launcher.
(In reply to comment #38) > Wouldn't that be a corner case anyway? Seems to me there would be little or no > point in restricting a users access to the eclipse root while permitting the > same user rights to mess around in the features and plugins directory. Don't forget that plugins and features can come from other places than the Eclipse directory. On UNIX, typically eclipse is read-only and the configuration area is below the user's home. Through the configuration area, additional extension locations can be defined. Each of these may be writable, and may hold plugins or features to be updated. So the startup that's happening outside these managed OSGi locations should be as small as possible. From the previous discussions it does seem, though, that handling those extension locations in the startup is not as trivial as one might think. The current "solution" appears to be that the "thin wrapper" (aka eclipse.exe) just takes that latest startup from the one known extension location below the root. In my opinion, it is acceptable that updating Eclipse "above the platform" is possible for any user by using extension locations, whereas updating Eclipse Platform itself is possible only with write access to the installation. Looking from that angle, a multi-stage boot which looks for a startup.new and copies it if it has been updated, seems acceptable.
(In reply to comment #39) > Looking from that angle, a multi-stage boot which looks for a startup.new and > copies it if it has been updated, seems acceptable. Thinking again, this seems equivalent to http://wiki.eclipse.org/index.php/Equinox_Startup_Issues#Do_nothing The only question is WHO copies the latest startup from plugins to the root: Is it the update manager when updating, or is it some clever script outside Eclipse. One nasty problem around this is, that once the startup.jar has been copied & renamed, it's not so easy any more to identify which version it actually is (so one could see whether the update has actually succeeded or not). My personal preference is: * When UM updates the Platform, it needs to do so in the Eclipse Installation, so it needs write access to plugins/ below the root anyway. If that's the case, I can't see why the same process shouldn't also have write access to the root. * When UM updates the Platform, it should at least try and copy startup_N.N.N.jar to root/startup.jar.
(In reply to comment #40) > My personal preference is: > * When UM updates the Platform, it needs to do so in the Eclipse Installation, > so it needs write access to plugins/ below the root anyway. If that's the > case, I can't see why the same process shouldn't also have write access > to the root. > * When UM updates the Platform, it should at least try and copy > startup_N.N.N.jar to root/startup.jar. > I share this preference, but as Andrew pointed out earlier, a direct copy to root will fail since that jar would be locked. Perhaps you meant startup.new?
(In reply to comment #41) > I share this preference, but as Andrew pointed out earlier, a direct copy to > root will fail since that jar would be locked. Perhaps you meant startup.new? - It would not be locked on UNIX (they don't lock, typically) - It would not be locked if started via eclipse.exe (since that directly uses the startup from plugins/) enough to go and try it, I think. Remember that we're only talking about updating the entire Eclipse platform to a new major release. Something that's not done too often. Or do you see a pressing need to update the entire platform from a headless application on Windows that launches Eclipse through java -jar startup.jar? Because when startup.new is created, the next question is who copies it into startup.jar and when.
(In reply to comment #42) > - It would not be locked if started via eclipse.exe (since that directly uses > the startup from plugins/) > Part of my proposal was that the launcher should use this startup.jar rather then searching for it under plugins/ and thereby same some time. I guess that's a very marginal improvement though (if any) so it doesn't really matter. I can live with that a headless invocation through startup.jar would fail to update itself on windows. When failing to copy it could print a message saying something like: "An attempt to copy plugins/org.eclipse.equinox.launcher_xxxx.jar to startup.jar failed. You need to perform this copy yourself after this process has terminated. For more information see http://..."
(In reply to comment #43) > Part of my proposal was that the launcher should use this startup.jar rather > then searching for it under plugins/ and thereby same some time. I guess > that's a very marginal improvement though (if any) so it doesn't really > matter. And, you couldn't update it. Advantage of searching the latest version under plugins is that when you update it, a NEW version is created rather than trying to overwrite the old one. > I can live with that a headless invocation through startup.jar would fail to > update itself on windows. When failing to copy it could print a message saying > something like: [...] > > "An attempt to copy plugins/org.eclipse.equinox.launcher_xxxx.jar to > startup.jar failed. You need to perform this copy yourself after this process > has terminated. For more information see http://..." Given that only those users see this, who run a headless update of the Eclipse Platform to a new major version, it seems fine for me.
FWIW when I did the first RCP tutorials they directed people to start their app with java -jar. This caused no end of trouble and questions about splash screens, init files, etc.. The next version just said to invoke the native launcher. Another advantage of a native launcher is that it can do things like check to see if you have the right version of Java (a common user error) and also it gets the right name on the process list and task bar ('eclipse' or whatever instead of 'java'). Java 6 has splash screens built in so it should be possible for a custom app to supply a Java port of the native launcher if they needed a 100% pure Java version for some reason. Some other ideas: the application could come with a version of eclipse.exe which was *not* a Windows program (i.e., it passed through stdout); and perhaps the 'thin jar' could just do a system exec of the native launcher. For the IDE and most RCP apps though, the JNI-enabled native launcher works great. Thanks for doing it.
> perhaps the 'thin jar' could just do a system exec of the native launcher. I was thinking about this the other day. A main class like this might actually work, at least on platforms for which we have a native launcher: public class Main { public static void main(String[] arguments) { try { Runtime.getRuntime().exec("eclipse"); } catch (IOException e) {...} } } (a bit goofy though)
I don't think this would be useful. Why not just execute the launcher to start with? Any problems you had with using the launcher would still exist (std streams, no ws and such). Any vm arguments you gave won't apply to the vm that is actually running eclipse, in fact the vm you started would not necessarily even be the same vm running eclipse. All it does it add an extra level of indirection.
We won't be making changes to the update manager for this in 3.3. My personal preference would simply be a script (.bat or .sh) similar to those Nick has already provided. With the addition of passing through arguments. The script could be made available for download and projects wishing to can include it in their own distributions. This is similar to the thin jar but avoids the classloader and security items outlined on the wiki.
(In reply to comment #48) > With the addition of passing through arguments. > The script could be made available for download and projects wishing to can > include it in their own distributions. > How does a script make life easier for those of us who wants to launch platform independently using Java? Seems to me the suggested change to the update manager would be comparable small effort. Why did you decide not do do that for 3.3?
You launch by calling the script instead of calling java. The script finds the launcher jar and calls java for you. Instead of running: "java -jar startup.jar" The script could be: "start.sh java -jar %LAUNCHER%" start.sh could simply execute whatever appeared in its arguments, but replace %LAUNCHER% with the correct jar name. We won't be making changes to update because there is basically no time: 1) We have no idea what the changes would involve as we have not done any investigation in update. There is plenty of reason to expect that it wouldn't be small or simple (it hardly ever is). 2) API freeze is now-ish (M6 is not that far away and eclipsecon takes up a week), we have no idea if any API would need to change. 3) Practically speaking, I am the one doing this work, I don't have commit rights on update (and neither does anyone else on our team) and there is still alot to do without trying to make update do root files
We also depend on executing "java -cp startup.jar" for a couple headless entry points (a command line build system and a command line debugger, both of which use a batch file to start Eclipse like: "java.exe -cp %ECLIPSE_HOME%\startup.jar org.eclipse.core.launcher.Main -application <myAppId> %*"). But we also have a Windows-based installer that installs our product by first inflating an Eclipse runtime, then calling the Eclipse update manager in headless mode to install each of our features. It also uses startup.jar called from the installer itself (not a batch file). So, from what I understand from the content of this bug and the wiki page, we could still use the same method provided we find the renamed (and versioned) startup.jar. It appears that we could also use the native launcher (eclipse.exe) itself if we didn't care about stdin/stdout/stderr on Windows (not an option for our debugger and builder). Is this true? So, with all of this discussion I still don't understand what you are going to recommend users do everywhere startup.jar is mentioned in the online Help. There are quite a few places where it is mentioned, in particular the headless update manager, running Ant via AntRunner, etc. What are you going to do about the headless update manager? In particular, all of the information on this help page: http://<help server>/help/topic/org.eclipse.platform.doc.isv/reference/misc/update_standalone.html?resultof=%22%73%74%61%72%74%75%70%2e%6a%61%72%22%20 What will the text on the new Help page look like? And will it be the same change to execute Ant headlessly (for PDE builds for instance)? What is the PDE build team planning on doing?
(In reply to comment #51) > What will the text on the new Help page look like? And will it be the same > change to execute Ant headlessly (for PDE builds for instance)? What is the > PDE build team planning on doing? How about something along the lines of http://wiki.eclipse.org/index.php/Starting_Eclipse_Commandline_With_Equinox_Launcher
(In reply to comment #52) > How about something along the lines of > http://wiki.eclipse.org/index.php/Starting_Eclipse_Commandline_With_Equinox_Launcher > One problem with this approach is that it does not take into account that the rights needed in order to launch can be somewhat different then the rights needed in order to upgrade the installation. This approach assumes you have write access to the actual installation folder. A minor adjustment to the update-manager to have it perform a similar copy would be quite different. While Andrew see plenty of reason to expect complications, I can not see any reason at all so I have to ask; what kind of complications are you thinking of? What's more work? Fixing the problem or fixing all documentation that mentions the startup.jar? The former would surely make more people happy. One thing to remember is that you haven't yet received the reaction from the user-community at large regarding this change. They don't monitor dev-lists and bugzillas so they haven't seen this yet. That reaction will come when 3.3.0 is released.
(In reply to comment #53) +1 to all Thomas said. During the update process there needs to be write-access to the installation anyway. During the update process, we can expect that startup.jar is writable because Eclipse was launched in UI mode (through eclipse.exe). So why not go and copy org.eclipse.equinox.launcher into a well-known name, like ../startup.jar (the well-known name could be something different if somebody really thinks it matters). It makes things SO much simpler. Why should everybody who wants to run Eclipse from ant or scripts need to figure out the right version of the Equinox Launcher? Even the Platform Basebuilder tricks around the issue by stripping the version number from the Equinox Launcher, such that they have a single entry point from their scripts. Not everybody can do that easily.
Martin, note that when eclipse is started through the eclipse.exe, the startup.jar is being used.
(In reply to comment #55) Hm, but how would that work if startup.jar doesn't really exist any more? It was my impression that since M5, exlipse.exe really finds the right version of plugins/org.eclipse.equinox.launcher_*.jar and uses that for launching.
Martin, in an attempt to clarify, I apparently made things worst :) Let me try again. Before 3.3 M5 (when startup.jar was still here), eclipse.exe looks for startup.jar and execute java on it, causing the file to be locked. Since 3.3M5, eclipse.exe searches for the launcher jar, execute java, causing the found file to be locked open. If now you are suggesting that during an installation the launcher jar could be copied at the root of an eclipse install and renamed into startup.jar, note that this will still cause problems for update since there are usecases where people want to run directly with java (therefore using the copied startup.jar to start) thus locking startup.jar and preventing its update.
How about having the eclipse.exe remain as is, i.e. *not* use the startup.jar but still provide the startup.jar as a copy of that launcher so that all headless users who wish to launch using Java can continue to use that.
(In reply to comment #58) +1 exactly what I'd suggest.
I'm not sure having the startup jar there, is much help above people just copying their own version of equinox.launcher to 'startup.jar' ... that would be equivalent, right? One thing that would help, I think, is to well document what "extra" things the executable does, that simplying calling java with the launcher wouldn't do. Lately I've noticed, for example, that using the executable with a -vm argument _does_ just launch java on the equinox jar, but with some options I've never seen before ... such as --launcher.library D:\builds\temp\eclipse\plugins\org.eclipse.equinox.launcher.w in32.win32.x86_1.0.0.v20070226\eclipse_1008.dll and -startup D:\builds\temp\eclipse\plugins\org.eclipse.equinox.launcher_1.0.0.v2007 0226.jar So, I assume if someone wanted to use their own 'java -jar equinox.launcher' invocation, they should also specify those other options? It's seems to me it's not currently documented what these are, or what these are for. (or, more likely, I just don't know where they are documented ... I just tried google searches).
What is the current state of this?
(In reply to comment #61) > What is the current state of this? > We have been using the new launcher story now for a full release. I don't see us reinstating the startup.jar at this point. I could be wrong but I think most folks have adapted to the new launcher story at this point and I recommend we close as wontfix. Andrew and Pascal, what are your thoughts?
The only issue raised in this bug that has not been addressed is the need for a version in the command line java -jar plugins/org.eclipse.equinox.launcher_1.0.100.v20080303.jar instead of the old java -jar startup.jar Some examples of scripts to handle this are provided here: http://wiki.eclipse.org/Starting_Eclipse_Commandline_With_Equinox_Launcher I agree with Tom that this should be closed as WONTFIX.
