Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 323572

Summary: Extension parser extension should not be declared in UI plugin
Product: [Modeling] TMF Reporter: Kai Kreuzer <kkreuzer>
Component: XtextAssignee: Project Inbox <tmf.xtext-inbox>
Status: CLOSED WONTFIX QA Contact:
Severity: enhancement    
Priority: P3 CC: ed, kkreuzer, mike, sebastian.zarnekow, sven.efftinge
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Whiteboard:

Description Kai Kreuzer CLA 2010-08-25 04:42:11 EDT
Build Identifier: Xtext 1.0.0.v201006170321

The extension for the extension point "org.eclipse.emf.ecore.extension_parser" is currently created in the plugin.xml of the DSL UI plugin and the according factory is also in src-gen of the UI plugin.
As parsing an Xtext resource should also be possible in a headless application (i.e. one without any UI related plugins), this extension should be moved to the DSL core plugin instead. This will involve moving the class AbstractGuiceAwareExecutableExtensionFactory as well, but as there are no dependencies to any UI classes, this should imho be no problem.


Reproducible: Always

Steps to Reproduce:
1. create a new Xtext project
Comment 1 Sven Efftinge CLA 2010-08-25 04:57:44 EDT
The problem is that we need to use the guice Injector from the UI project in order to instantiate any components.
Comment 2 Kai Kreuzer CLA 2010-12-30 15:51:44 EST
Couldn't there be different injectors being used for core and UI plugin?
The core injector should then be something similar to what is done in the standalone setup method.
Do you have any other suggestion about how to get resources loaded if the UI plugin is not present?
Comment 3 Sven Efftinge CLA 2010-12-31 01:03:06 EST
The ResourceFactory needs to be constructed by the injector from the UI bundle, because it needs components which live there (i.e. resources based container manager, etc.). 

If you don't want the UI bundle you could:
1) initialize programmatically using the standalone setup.
2) create a third bundle which contains the runtime extensions points only and maintains the injector.

I'm closing this as won't fix as sufficient workarounds are available and the use case is rare. 
Please reopen if I've missed anything.
Comment 4 Sven Efftinge CLA 2011-03-26 16:02:41 EDT
see last comment
Comment 5 Michael Vorburger CLA 2012-06-15 09:39:19 EDT
This is a pain point for using Xtext in a Headless Eclipse Product - no plans to address this?  We can probably "hack" something so that in the UI variant of our Product we use the Xtext UI plug-ins, and in the headless variant we use Standalone, or (... somehow...) custom Guice modules which initialize Xtext for use within Eclipse but without the UI parts. It would be nicer if Xtext offered this out of the box of course..
Comment 6 Sebastian Zarnekow CLA 2019-03-09 10:01:43 EST
*** Bug 545238 has been marked as a duplicate of this bug. ***