Community
Participate
Working Groups
Default implementation of Xtext EmbededEditor depends on org.eclipse.core.internal.resources.Workspace which is at very beginning injected. The Workspace is not running and therefore the Editor doesn't work as UI component in e4 Application.
Can you give me a pointer where the editor depends illegally on IWorkspace. I searched the complete package and did not find something.
Sorry, this was not Workspace but Workbench, which i meant. In my Opinion is the Problem in org.eclipse.xtext.ui.shared.SharedStateModule line 85 method configureIWorkbench PlatformUI.isWorkbenchRunning is newer True in e4 Application model and thus is the instance of the Workbench class never put into the DI container E4 Aplication model uses org.eclipse.e4.ui.internal.workbench.E4Workbench and Interface org.eclipse.e4.ui.workbench.IWorkbench The problem occurs then in org.eclipse.xtext.ui.editor.embedded.EmbeddedEditorActions.initialise line 124 because workbench is not in DI container. The only way is probabably to create another e4 implementation of IWorkspace
Thanks for the clarification and analyzing the issue. So with e4 you'd have to bind your own implementation of org.eclipse.xtext.ui.editor.embedded.EmbeddedEditorActions.Factory or at least guard the access to the workbench to prevent NPEs, I guess.
The problem is that core Xtext plugins calls PlatformUI.getWorkbench(). - to use shared images - access system menus - read system preferences... There is no possibility to use DI injector to change this. In E4 Apllication is the class org.eclipse.e4.ui.internal.Workbench never created and therefore the Embedded Xtext Editor crashes on many places. Is there chance to make the Framework independent from PlatformUI Workbench ?
I can reproduce this issue and can confirm that it also occurs when using OCL (which leverages xtext functionality). For example, one dependency can be found in org.eclipse.xtext.ui.editor.GlobalURIEditorOpener which depends on getting the IWorkbench injected.
I did a bit of hacking to make it work. I had to subclass EmbeddedEditorActions (+ Factory) and EmbeddedEditorFactory (+ Builder) and override a couple of methods, that were using the workbench. In addition I needed to Hack XtextPluginImages which unfortunately is not exported and is static. I needed to set the static ImageRegistry such that the problematic initialization doesn't happen. Bundle[] bundles = ArithmeticsActivator.getInstance().getBundle().getBundleContext().getBundles(); for (int i = 0; i < bundles.length; i++) { Bundle bundle = bundles[i]; if (bundle.getSymbolicName().equals("org.eclipse.xtext.ui")) { Class<?> loadClass = bundle.loadClass("org.eclipse.xtext.ui.internal.XtextPluginImages"); Field field = loadClass.getDeclaredField("PLUGIN_REGISTRY"); field.setAccessible(true); field.set(null, new ImageRegistry() /*TODO replace with properly initialized one */); } } We should make this easier :-)
Are there news about that issue?
(In reply to Sven Klemm from comment #7) > Are there news about that issue? No, we unfortunately didn't come around to work on this. I'm sorry.
I spend another couple of hours on this and found more places where PlatformUI.getWorkbench() is called. These are places in older Eclipse code, which Xtext uses. I basically replaced occasion after occasion until it really didn't make much sense to change the existing embedded editor code more but rather put one for e4 next to it. Nasty singletons... Putting an e4 version aside would be some effort and given the relatively low adoption of e4 and the existence of the compatibility layer, I don't want to invest resources/money on it. I would however be happy to help contributors getting this done. Alternatively someone could of course just pay us (itemis). One thing I haven't quite understood so far is what the drawbacks of running in e3 compatibility mode are. Could someone explain?
Many thanks for efforts on resolving this issue. To run an Xtext embedded editor in Eclipse 4, there must be probably mixed mode used. While this can be a possible solution, it is officially not supported (according to L.Vogel). See : http://www.eclipse.org/community/eclipse_newsletter/2013/february/article3.php
Created attachment 254080 [details] XText 2.7.2 sample from wizard integrated into E4 Application from E4 Wizard run with E3 compatibility layer Our target application has a pure E4 application model without any JDT functionality yet and is not compatible with the IDE application model. When using the E3 compatibility layer and with that enabling the E3 singletons we get lots of exceptions and the component tree is automatically polluted from dirty E3 code with unneeded and in most cases invisible items like quick access and we receive an empty area for the top level trim bar. Since we still work with 4.2 target platform, the model spy is not working with our application, so it is more difficult to find out what is polluting the model. With 4.4 platform the problems were slightly different but not completely solved. At first tries we also faced a problem where our main application part remained empty although it was in the component tree, but it always got size 0,0 and even no programmatic resize and layout helped and we found no solution for that yet. After testing again today at least this problem disappeared, but since we do not know why it was there and by which change it disappeared, we see great danger in activating the compatibility layer for production use. We found no effordable way to debug this in our IDE and so there is no way to provide support if this happens on customer's machine again. A similar issue can be reproduced with the here provided sample application generated with the E4 application wizard, extended by a DSL from the XText wizard and switched to an application using the compaibility layer. The pure E4 application at least runs, but cannot initialize the XText embedded editor, the E3Application using the mixed E3 compatibility layer, as we understood it by using PlatformUI.createAndRunWorkbench() from a derived E4Application, only shows an empty frame and in this case even does not initialize the part from the E4 application model. In our application meanwhile we at least get our application model initialized. So even if we can solve the remaining cosmetic problems and the exceptions like NPEs in ContributedPartRenderer and devide by zero in TrimBarLayout we would not feel happy with activating unnecessary code that assumes running in the eclipse PDE and cannot be controlled since it works with the E3 singletons. And we do not want to patch eclipse plugins. But after debugging a lot without compatibility layer my impression is also that there will be no effordable way to use the embedded xtext editor without the E3 compatibility layer.
Tom (CC) is working on a JavaFX port of the editing framework together with Xtext support. See his recent post on this matter : http://tomsondev.bestsolution.at/2015/05/20/code-editors-in-general-with-javafx/ AFAIK he's using eclipse.text under the hood, so maybe there is something that could help for e4 as well. Also our ongoing effort to extract IDE services from eclipse ui, might be a starting point.
