Community
Participate
Working Groups
To launch an equinox runtime via the Eclipse Launcher wizard, you must have the "org.eclipse.osgi" bundle selected in the line-up. If it's not, the tooling tells you it must be included as soon as you hit the Run button -- so you have to re-open the launch wizard, add it manually, and try again. To reproduce: 1. Create a new Equinox OSGi Framework launch configuration. 2. Click "Deselect All". You should have 0 bundles selected. 3. Click the "Validate Plug-in Set" button and you'll get the "No problems were detected in the selected set of plug-ins." dialog. 4. Click the "Run" button and you'll get the "The org.eclipse.osgi plug-in is missing from this configuration." dialog. If this IS a required bundle as far as the tooling is concerned, then: a) the "Add Required Plugins" button should add it if it is missing b) the "Validate Plugin Set" button should warn the user if the bundle is missing c) the launch wizard should not close after hitting "Run" if the bundle is missing
I believe that Brett was testing on Eclipse 3.2.2 and Equinox 3.2.2, where his problem desciption is accurate. This is even more problematic on Eclipse 3.3 M5, since an NPE is thrown and written to the .log: !ENTRY org.eclipse.core.jobs 4 2 2007-02-27 10:57:31.314 !MESSAGE An internal error occurred during: "Launching". !STACK 0 java.lang.NullPointerException at java.util.Hashtable.put(Unknown Source) at org.eclipse.pde.ui.launcher.EquinoxLaunchConfiguration.saveConfigurationFile(EquinoxLaunchConfiguration.java:81) at org.eclipse.pde.ui.launcher.EquinoxLaunchConfiguration.getProgramArguments(EquinoxLaunchConfiguration.java:63) at org.eclipse.pde.ui.launcher.AbstractPDELaunchConfiguration.launch(AbstractPDELaunchConfiguration.java:75) at org.eclipse.pde.ui.launcher.OSGiLaunchConfigurationDelegate.launch(OSGiLaunchConfigurationDelegate.java:48) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:747) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:613) at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.java:819) at org.eclipse.debug.internal.ui.DebugUIPlugin$7.run(DebugUIPlugin.java:1013) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
I'm also seeing the NPE. In addition, the launch configuration fails to start with a 'An internal error occurred during: "Launching"' dialog.
We will address this bug for M6. However, I find it interesting (and alarming :) that people are launching the framework with no bundles selected. What are you expecting it to do without the osgi framework bundle?
I wouldn't expect anybody to intentionally attempt to launch with the framework bundle. If a user forgets to select the framework bundle, however, a NPE does not help them determine the problem.
Sometimes it's nice to launch an empty runtime just to make sure the launcher works... or if you're planning on installing bundles via their URLs.
Heated agreement. My preference is to typically start with no bundles selected, and then to hand pick only those that I want. This is pretty common when using Equinox for OSGi application development, rather than Eclipse plug-in development. In the embedded space you're trained to truly understand your application dependencies and to resist dependency creep. Writing this comment inspired me to create bug 177444. :-)
I understand the 'start with no bundles and then install on-demand' scenario. You won't get very far without at least the osgi bundle though. That was my point. From comment 4, it seems that people are inadvertently getting themselves into the situation by pressing 'Deselect All' and launching, not realizing that there is no such thing as free lunch, and they don't get osgi for free.
need to keep in mind cases where you are launching other frameworks where the bundle is not org.eclipse.osgi.
In 3.3, the Equinox launcher has been renamed to the 'OSGi Framework' launcher and was made more generic in that you can launch with other OSGi frameworks. Non-equinox frameworks must register themselves and their launcher delegates (ie. the class that does the actual launching) via an org.eclipse.pde.ui.osgiFrameworks extension. Now back to this defect: The launch configuration itself should be org.eclipse.osgi-agnostic and must treat all frameworks equally without particular knowledge of any framework requirements. The only thing that can be done in the launch configuration itself is the feedback message when you press the Validate button. Instead of telling you that everything is fine, it should tell you that 'no bundles are selected'. A no-bundle-is-selected may be fine for some other framework, so this is not an error state as far as the launch configuration is concerned. Now when you come to launch the launch config with the Equinox framework, the PDE Equinox launch delegate gets called. This class is org.eclipse.osgi-aware and tells you that osgi has not been selected (in 3.2) or throws an NPE (in 3.3 ;). We could tweak this class to be more helpful and perhaps offer to find/check an osgi plugin for you if you are lauching with no bundles.
Would this be a good case for the OSGi launch delegate to be able to participate in the "Add Required Plugins" and/or "Validate Plugin Set" logic via an extension point? Then any framework-specific bundles could be selected correctly, avoiding any errors/warnings after the launch. From the user perspective it's all the same wizard.
yes, that would make sense. Unfortunately, API freeze for 3.3 is effectively today and technically next week. I would not be comfortable committing to API additions at this point. Incidentally, and somewhat unrelated, all references to 'plug-in' will be replaced by 'bundle' in the OSGi framework launcher as of M6.
It's like Christmas in March... I didn't dare ask for a rename, but I'm happy to hear it's happening. Bundle developers unite!
This is all in an effort to reduce the amount of PDE slandering in public ;) here is a passage from a certain eclipsecon talk abstract: "we explain some of the gaps we discovered in the Eclipse tooling and the approaches that we have taken to fill them while developing, deploying, and maintaining these complex applications running on over a dozen remote devices. "
Fixed. Since the launch configuration is now a generic OSGi launch configuration, not an Equinox launch configuration, we cannot put any org.eclipse.osgi logic in it. However, when it comes to launching time, the Equinox launcher delegate that gets called now auto-manages the org.eclipse.osgi plug-in. If it is missing, it finds the best suitable osgi plug-in (ie. a workspace copy has precedence over a target copy of the osgi plug-in) and we launch with it. If for some reason, we can't find osgi in the workspace or target, the launch fails with an error message indicating so. This auto-management of osgi for Equinox launches is consistent with the auto-management of bootstrap code for Eclipse app launches and auto-discovery of JUnit plug-ins for JUnit Plug-ins launches.
>> Comment #14 From Wassim Melhem 2007-04-29 02:45:01 [reply] Clearly you were up late last night, or maybe just up very early this morning! Thanks, Wassim.
>Clearly you were up late last night, or maybe just up very early this >morning! Another explanation could be that I am working out of my home office in Cairo, Egypt.
