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

Bug 435246

Summary:	[dot4zest] Do not call DotStandaloneSetup.doSetup in Eclipse environment
Product:	[Tools] GEF	Reporter:	Sebastian Zarnekow <sebastian.zarnekow>
Component:	GEF DOT	Assignee:	gef-inbox <gef-inbox>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	nyssen, steeg, zoltan.ujhelyi
Version:	unspecified
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:

Description Sebastian Zarnekow

2014-05-20 03:24:41 EDT

This will override registered services with implementations that cannot be used from within Eclipse.

Maybe I'm wrong, but it looks like this is done in DotAST (https://eclipse.googlesource.com/gef/org.eclipse.gef4/+/b93be39802269431dc7cf8bd8ff56d04a5f1f794/org.eclipse.gef4.zest.dot.core/src/org/eclipse/gef4/zest/internal/dot/DotAst.java). I found that culprit when digging into bug 435148

Comment 1 Alexander Nyßen

2014-05-20 03:57:19 EDT

Yes, the call is actually there. What is the problem and how to do it right?

Comment 2 Zoltan Ujhelyi

2014-05-20 04:22:17 EDT

The problem is that Xtext has different binding for Eclipse and non-Eclipse environments, and using the non-Eclipse binding, started by the StandaloneSetup.doSetup method causes all kinds of issues runtime (e.g. in the EMF-IncQuery project we had some hard-to-understand classcastexceptions related to it).

The right way to do it is not to call the StandaloneSetup inside the API, but rely on the language being already registered. For Eclipse environments, this is done via extension points of the UI project of the language; for Eclipse-less environments the StandaloneSetup needs to be called once per application.

Comment 3 Alexander Nyßen

2014-05-20 04:45:31 EDT

I am not sure about the concrete use case here, but I assume we may then simply guard the call with something like (if(!Eclipse.isRunning()){}...

Comment 4 Sebastian Zarnekow

2014-05-20 05:00:19 EDT

Or you could check whether there's already a resource factory registered for your file extension. This would help to execute the standalone setup only once

Comment 5 Fabian Steeg

2014-05-20 12:14:45 EDT

Attempted fix based on Sebastian's suggestion from comment #4:
http://git.eclipse.org/c/gef/org.eclipse.gef4.git/commit/?id=5de17cfa689decba

Comment 6 Sebastian Zarnekow

2014-05-21 03:24:13 EDT

(In reply to Fabian Steeg from comment #5)
> Attempted fix based on Sebastian's suggestion from comment #4:
> http://git.eclipse.org/c/gef/org.eclipse.gef4.git/commit/?id=5de17cfa689decba

Is there a nightly build or an update site that can be consumed to test drive the fix?

Comment 7 Alexander Nyßen

2014-05-21 03:26:25 EDT

(In reply to Sebastian Zarnekow from comment #6)
> (In reply to Fabian Steeg from comment #5)
> > Attempted fix based on Sebastian's suggestion from comment #4:
> > http://git.eclipse.org/c/gef/org.eclipse.gef4.git/commit/?id=5de17cfa689decba
> 
> Is there a nightly build or an update site that can be consumed to test
> drive the fix?

Yes, it's included on https://hudson.eclipse.org/hudson/job/gef4-master/lastSuccessfulBuild/artifact/update-site

Comment 8 Alexander Nyßen

2014-07-12 11:43:14 EDT

Sebastian, may we resolve this one as fixed?

Comment 9 Sebastian Zarnekow

2014-07-14 03:14:17 EDT

Yes, I think so.