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

Bug 326219

Summary:	[core] support for headless build
Product:	[Modeling] TMF	Reporter:	Knut Wannheden <knut.wannheden>
Component:	Xtext	Assignee:	Project Inbox <tmf.xtext-inbox>
Status:	NEW ---	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	christian.dietrich.opensource, dennis.huebner, mike, moritz.eysholdt, stephane, sven.efftinge
Version:	1.0.0
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:
Bug Depends on:
Bug Blocks:	335652

Description Knut Wannheden

2010-09-25 02:21:53 EDT

We need the possibility to run the XtextBuilder in a headless environment, just like in the JDT using the aptBuild application. This has far reaching consequences as it means moving some bindings from the UI plugin to the runtime plugin and probably introduce a third module to support headless mode (in addition to standalone and UI mode).

Comment 1 Sven Efftinge

2010-09-25 04:28:25 EDT

Please elaborate on your findings. What do you think needs to be done, which findings have to be moved?

Comment 2 Knut Wannheden

2010-09-25 06:39:45 EDT

Hi Sven,

I have not yet studied this in detail. The first thing that comes to mind is the EMF resource factory extension. This in turn requires a Guice extension factory in the runtime plugin and thus probably also hierarchical Guice injectors. 

I will try to take a look at this next week. What is your gut feeling on this?

Comment 3 Knut Wannheden

2010-09-25 08:28:13 EDT

We've already discussed the matter of moving the resource factory before. See bug 264578.

Comment 4 Sven Efftinge

2010-09-25 10:13:30 EDT

my gut feeling is, that it should be possible to use the builder in a headless mode.
But I hope we can find a solution without re-architecting the bundles.

Comment 5 Knut Wannheden

2010-09-27 07:17:48 EDT

I just successfully ran a headless build. All I had to do was change all the "org.eclipse.xtext.extension_resourceServiceProvider" extensions to use the "org.eclipse.xtext.resource.IResourceServiceProvider" implementation (instead of "org.eclipse.xtext.ui.resource.IResourceUIServiceProvider").

The reason is that DefaultResourceUIServiceProvider has @LanguageSpecific IURIEditorOpener injected, which in turn has IWorkbench injected.

Also I had to bind IWorkspace to a dummy implementation, as it is used in org.eclipse.xtext.ui.shared.internal.Activator. Also IWorkbench requires a binding to a dummy implementation, as it is used by EMFBasedPersister.

Comment 6 Christian Dietrich

2017-08-04 07:58:02 EDT

see https://github.com/eclipse/xtext-eclipse/issues/311 as well