Community
Participate
Working Groups
After upgrading to M5 from Eclipse 3.2, I can no longer launch Equinox configurations unless I copy startup.jar to my target platform directory. This was not required in 3.2. To reproduce, create a new target directory. Set the plugin target platform to the new directory. Attempt to launch a new 'OSGi Framework' launch configuration. I get the following error dialog: 'Launching failed. Required Library "startup.jar" is missing from the target platform.'
what is in that "new target directory"?
Sorry. To reproduce, you only need org.eclipse.osgi_3.3.0.v20070208.jar in your target directory.
Using Eclipse 3.3 M6 I am seeing this too. I too have a hand-crafted target platform (doesn't everyone? <g>), consisting of Equinox + some of my own stuff, but certainly not the Eclipse IDE plugins. Wassim pointed me to a solution, which is to add the following plug-ins (copied from the Eclipse IDE plugins folder) to my platform target: org.eclipse.equinox.launcher.win32.win32.x86_1.0.0.v20070318/ org.eclipse.equinox.launcher_1.0.0.v20070319.jar While this solution certainly works, it seems that since I don't actually need these plug-ins selected when I launch the Equinox framework, maybe the right answer here is for the Equinox launch configuration to somehow slurp them from the Eclipse IDE's plugins folder at runtime. As things are today in M6 this feels very much like a regression and will break everyone that has a custom target platform. Please can this have a target of 3.3 M7? Thanks.
If nothing else this is a conceptual problem. From a command line point of view we tell people that they can run Equinox using java -jar org.eclipse.osgi.jar -console yet when they are developing and launching today, they cannot do this. A further issue is that they could do this in the past. Certainly using the launcher JAR from the IDE host could work in some cases as a fall back but in general this is not a good thing. What happens when your IDE and target are of mixed version etc? In the end someone building a system often wants the launcher (splash, using teh exe, ...) so hiding it from them is hiding the fact that they need to put it in their configurations etc. Previously with startup.jar it was all handled for them as part of the root files (i.e., this function was lumped/paired with the exe). Now we have the launcher as a "bundle" to empower other scenarios. Perhaps with great power comes great responsibility? Not sure I believe that but Side/secondary issues/comments: - The message says that startup.jar is missing but in fact the user needs the org.eclipse.equinox.launcher_vXXX.jar - to get this working you only need the equinox.launcher JAR in your system. you do not need the fragment. So, what to do? - have PDE do something under the covers and find/put the launcher JAR in the launch configs - require the users to know about the launcher JAR and put it in the configs themselves - consider having launcher JAR equivalent function in the osgi JAR so in fact the launcher JAR is not needed.
Jeff makes some good points in comment 4. I agree that the error message is both wrong and misleading. I also strongly agree with with point regarding developing using one version of the tools while developing an application targeted at another version. My vote would be for the launching code to be included in one of the core Equinox bundles (would that be org.eclipse.osgi?). I think this is the right thing for the following reasons: 1. Having the launching code separate is confusing since you never actually have to install them from an OSGi point of view. 2. Having the launching bundle(s) available to select in the launch config dialog is confusing, and what does checking them mean anyway? 3. The launching bundles and the Equinox OSGi framework bundles should probably always be used together and there's not reason for doing otherwise. 4. The Equinox OSGi framework won't launch without the launchng code. 5. Simpler == Better. For these reasons I believe that the launching jar(s) should be indivisible from the Equinox OSGi bundles. Comments, suggestions, corrections? <g>
We shouldn't get hung up on the "startup.jar is missing" error message, which clearly needs to be updated to reflect the new launching story. As for what to do here, people have never had to worry about the bootstrap code nor where it is for years now. They like that it magically happens and let's keep it that way. The org.eclipse.equinox.launcher.** plugin/fragment should not be managed by the user and should not be part of the "Add Required Plug-ins/Bundles", since no one is requiring them in the manifest.mf. They should be handled implicitly by PDE, as we have always implicitly handled starup.jar. Therefore, as we ship 3.3, PDE has to be self-sufficient to launch any >= 3.0 target platform without the need for a startup.jar. bug 178327 would help us get there. When launching: 1. if the osgi version we are launching with is >= 3.3, we use the new org.eclipse.equinox.launcher.Main. 2. if the osgi version is < 3.3, we use the old org.eclipse.core.launcher.Main Where do we look for org.eclipse.equinox.launcher.Main? We look for the org.eclipse.equinox.launcher.* plug-in in the workspace, then the target, then we fall back on the one in the host installation. Where do we look for org.eclipse.core.launcher.Main? we look for the org.ecipse.platform plug-in in the workspace, then we look up for startup.jar in the target, then we look for the old Main class in the org.eclipse.equinox.launcher.* plug-in in the host installation. That is why bug 178327 is important. Note that we have to do the same thing whe packaging RCP products. ie. we have to implicitly startup.jar or the launcher plugin/fragment implicitly.
ok that sounds like a reasonable plan. There will still IMHO be a bit of a disconnect because the launcher "bundle" is not in the root files so people may be confused as to why they need/have it in their bundle set when they deploy but did not have to mess with it in their launch configs. In the long run (e.g., after 3.3) it would be great to review this yet again and see if we can simplify the launching story (both in execution and in code form)
A related issue is that the org.eclipse.equinox.launcher is still missing from the equinox sdk zip. See bug 175383.
Fixed as per comment 6.
