Community
Participate
Working Groups
Won't start, on existing workspaces or new ones. Log: !SESSION 2010-10-26 14:12:47.007 ----------------------------------------------- eclipse.buildId=I20101025-1602 java.version=1.6.0_22 java.vendor=Apple Inc. BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=en_US Framework arguments: -keyring /Users/bokowski/.eclipse_keyring -showlocation Command-line arguments: -os macosx -ws cocoa -arch x86_64 -keyring /Users/bokowski/.eclipse_keyring -showlocation !ENTRY org.eclipse.core.net 1 0 2010-10-26 14:12:55.640 !MESSAGE System property http.nonProxyHosts has been set to local|*.local|169.254/16|*.169.254/16 by an external source. This value w ill be overwritten using the values from the preferences !ENTRY org.eclipse.ui 4 4 2010-10-26 14:12:56.407 !MESSAGE Unable to create menu item "null", command "org.eclipse.ui.cocoa.minimizeWindow" not defined !ENTRY org.eclipse.ui 4 4 2010-10-26 14:12:56.407 !MESSAGE Unable to create menu item "null", command "org.eclipse.ui.cocoa.zoomWindow" not defined !ENTRY org.eclipse.ui 4 4 2010-10-26 14:12:56.407 !MESSAGE Unable to create menu item "null", command "org.eclipse.ui.cocoa.arrangeWindowsInFront" not defined !ENTRY org.eclipse.osgi 4 0 2010-10-26 14:12:58.729 !MESSAGE Application error !STACK 1 org.eclipse.e4.core.di.InjectionException: java.lang.NullPointerException at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:59) at org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:796) at org.eclipse.e4.core.internal.di.InjectorImpl.inject(InjectorImpl.java:104) at org.eclipse.e4.core.internal.di.InjectorImpl.inject(InjectorImpl.java:74) at org.eclipse.e4.core.contexts.ContextInjectionFactory.inject(ContextInjectionFactory.java:72) at org.eclipse.ui.internal.Workbench.createWorkbenchWindow(Workbench.java:1177) at org.eclipse.ui.internal.Workbench.getActiveWorkbenchWindow(Workbench.java:1151) at org.eclipse.ui.internal.services.WorkbenchSourceProvider.updateActiveShell(WorkbenchSourceProvider.java:932) at org.eclipse.ui.internal.services.WorkbenchSourceProvider.getCurrentState(WorkbenchSourceProvider.java:133) at org.eclipse.ui.internal.services.WorkbenchSourceProvider$6.handleEvent(WorkbenchSourceProvider.java:692) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Display.filterEvent(Display.java:1041) at org.eclipse.swt.widgets.Display.sendEvent(Display.java:3955) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1424) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1447) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1428) at org.eclipse.swt.widgets.Shell.windowDidBecomeKey(Shell.java:2020) at org.eclipse.swt.widgets.Display.windowProc(Display.java:5294) at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method) at org.eclipse.swt.widgets.Widget.callSuper(Widget.java:213) at org.eclipse.swt.widgets.Widget.becomeKeyWindow(Widget.java:355) at org.eclipse.swt.widgets.Shell.becomeKeyWindow(Shell.java:490) at org.eclipse.swt.widgets.Display.windowProc(Display.java:5118) at org.eclipse.swt.internal.cocoa.OS.objc_msgSend(Native Method) at org.eclipse.swt.internal.cocoa.NSWindow.makeKeyAndOrderFront(NSWindow.java:190) at org.eclipse.swt.widgets.Shell.makeKeyAndOrderFront(Shell.java:1211) at org.eclipse.swt.widgets.Shell.setWindowVisible(Shell.java:1867) at org.eclipse.swt.widgets.Shell.open(Shell.java:1289) at org.eclipse.e4.ui.workbench.renderers.swt.WBWRenderer.postProcess(WBWRenderer.java:539) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:494) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:554) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$6.run(PartRenderingEngine.java:740) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:692) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:104) at org.eclipse.ui.internal.Workbench$3.run(Workbench.java:545) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:527) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:621) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:576) at org.eclipse.equinox.launcher.Main.run(Main.java:1409) Caused by: java.lang.NullPointerException at org.eclipse.ui.internal.menus.MenuHelper.createItem(MenuHelper.java:586) at org.eclipse.ui.internal.WorkbenchWindow.fill(WorkbenchWindow.java:611) at org.eclipse.ui.internal.WorkbenchWindow.fill(WorkbenchWindow.java:606) at org.eclipse.ui.internal.WorkbenchWindow.setup(WorkbenchWindow.java:500) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:52) ... 51 more
(In reply to comment #0) > Caused by: java.lang.NullPointerException > at > org.eclipse.ui.internal.menus.MenuHelper.createItem(MenuHelper.java:586) > at > org.eclipse.ui.internal.WorkbenchWindow.fill(WorkbenchWindow.java:611) This indicates that the CommandContributionItem is returning 'null' for getCommand(). Likely caused by all those "not defined" error messages above the stack trace.
I20101026-0203 doesn't die, but it doesn't have any menus. (In reply to comment #1) > This indicates that the CommandContributionItem is returning 'null' for > getCommand(). > > Likely caused by all those "not defined" error messages above the stack trace. That's exactly right.
Created attachment 181772 [details] Protect MenuHelper#createItem() with an if-null guard The easy fix is to guard against a null command. (Warning: my CVS tree is taking eons to update, so I've hacked this patch to be in the workspace patch format. I may have messed it up.) The underlying problem is that there have been several features added to the 3.x Cocoa fragment that haven't been migrated to the e4 variant. I've filed that as bug 328770.
Fix released to HEAD. Should be in >20101026
I've released this for the next I build.
This bug seems to be a consequence of changes made in the bug 201696 and repeated in the bug 327503. Those changes put Cocoa-specific "declarations" in the general bundle ("org.eclipse.ui.ide") and "implementations" in the specific fragment ("org.eclipse.ui.cocoa"). See the WorkbenchActionBuilder and its uses of Util.isCocoa().
(In reply to comment #6) > Those changes put Cocoa-specific "declarations" in the general bundle > ("org.eclipse.ui.ide") and "implementations" in the specific fragment > ("org.eclipse.ui.cocoa"). See the WorkbenchActionBuilder and its uses of > Util.isCocoa(). What is the better way to handle it? Put the commands in the org.eclipse.ui and the handlers in the cocoa fragment?
Is it possible to put all Cocoa-specific pieces in the Cocoa fragment? The way it is done now, the bundle "org.eclipse.ui.ide" has a factual dependency on the fragment "org.eclipse.ui.cocoa".
(In reply to comment #8) > Is it possible to put all Cocoa-specific pieces in the Cocoa fragment? > > The way it is done now, the bundle "org.eclipse.ui.ide" has a factual > dependency on the fragment "org.eclipse.ui.cocoa". Except for the usage of these commands all those Cocoa specific pieces are already in that fragment. We can contribute these items using commands to the Window menu from the cocoa fragment. But that will cause these items to appear in the RCP apps, whether they like it or not. A perfect fix would be to contribute these commands from a new o.e.ui.ide.cocoa fragment, but do we have to go that far?
(In reply to comment #9) > Except for the usage of these commands all those Cocoa specific pieces are > already in that fragment. We can contribute these items using commands to the > Window menu from the cocoa fragment. But that will cause these items to appear > in the RCP apps, whether they like it or not. A perfect fix would be to > contribute these commands from a new o.e.ui.ide.cocoa fragment, but do we have > to go that far? I think a perfect fix, or a variation, may be necessary. My primary concern is the maintenance hassle for the e4 code. I ported the About, Quit, and Preference menu-item remapping and close-dialog functionality from org.eclipse.ui.cocoa for e4 to use the e4 mechanisms -- these changes are very useful for pure e4 apps. Since the port replaced the implementation, and since there was no other functionality in the .ui.cocoa fragment, the 4.x platform doesn't include org.eclipse.ui.cocoa. I see three choices: (1) keep .ui.cocoa and e4.ui.workbench.swt.cocoa in sync (so port the changes over), (2) figure out how to make .ui.cocoa and .e4.ui.workbench.swt.cocoa be able to co-exist, or (3) break out the new functionality into a separate fragment. I suspect (2) is impossible and (1) seems to be less than optimal. I'll also point out that these changes actually make sense for Carbon too. Maybe these new commands and handlers should be put in a .macosx fragment instead. And on some further thought, I wonder if the commands shouldn't be genericized: 'close dialog', 'bring to front', 'zoom' all make sense on other platforms too. They could all be put in .ide or .ui and controlled by Util.isMac().
(In reply to comment #9) > Except for the usage of these commands all those Cocoa specific pieces are > already in that fragment. We can contribute these items using commands to the > Window menu from the cocoa fragment. But that will cause these items to appear > in the RCP apps, whether they like it or not. A perfect fix would be to > contribute these commands from a new o.e.ui.ide.cocoa fragment, but do we have > to go that far? If these items are applicable to e4 and 3.x, then this just becomes a 3.x new functionality problem (for which we're still talking about a solution, we only have a manual one). If the ui.cocoa commands are not relevent in e4/4.1, then we have 3 choices: 1) work the way they are now. Commands are the representation of abstract behaviour, and simply using a command id does not represent a hard coupling. 2) if we move the commands to ui.cocoa, then all uses of them (in the WorkbenchActionBuilder, for example), need to be guarded with command.isDefined() as well. 2b) contribute them using o.e.ui.menus from org.eclipse.ui.cocoa, and enhance org.eclipse.core.internal.expressions.propertytester.PlatformPropertyTester so you can test the application (org.eclipse.ui.ide.workbench) 3) they can be placed in org.eclipse.ui.ide.application and still targetted at the Mac ... this would still require them to be defined, however. PW
Marking this as resolved, since it was. Any discussion should happen on bug 328770.
