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

Bug 326407

Summary:	ResourceSet is not an XtextResourceSet
Product:	[Modeling] TMF	Reporter:	Ed Willink <ed>
Component:	Xtext	Assignee:	Project Inbox <tmf.xtext-inbox>
Status:	NEW ---	QA Contact:
Severity:	normal
Priority:	P5	CC:	jan, sven.efftinge
Version:	unspecified
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:

Description Ed Willink

2010-09-28 08:57:42 EDT

XtextResourceSet extends ResourceSet which causes problems for traditional modeling applications that use ResourceSet.

For instance, when opening an Xtext (text file) that uses JDT Types with the Sample Ecore Editor the types fail to resolve because in XtextResourceSetBasedProjectProvider.getJavaProject there is an instanceof test that fails and so no IJavaProject is identified.

I have learned in my own code that it is a very bad idea to extend ResourceSet since it is too fundamental to EMF. Instead, I use a ResourceSet.eAdapter so that my enhanced ResourceSet can coexist with anyone else's and so that a ResourceSet created by someone else can be enhanced to support my functionality.

Please consider reimplementing XtextResourceSet as a ResourceSet Adapter.

Comment 1 Sven Efftinge

2010-09-28 09:25:00 EDT

We don't even need an adapter, since the only thing we do is hooking the URIConverter, which can be set from outside.
However, the fundamental problem is, that the JvmTypes need a context (IJavaProject) in order to work properly. Since the sample ecore editor doesn't know about this, the context won't be there and the types won't be resolvable.

Comment 2 Jan Koehnlein

2010-09-28 09:34:00 EDT

Situation is a bit worse: We have two subclasses of XtextResourceSet:

1) SynchronizedXtextResourceSet synchronizes the access to the contents of the resource set. This has been introduced to get rid of race conditions during the Ecore model inference.
2) ResourceSetReferencingResourceSet needed for global scoping.

I suppose these cannot be replaced by using eAdapters.

Comment 3 Ed Willink

2010-09-28 11:16:45 EDT

(In reply to comment #1)
> However, the fundamental problem is, that the JvmTypes need a context
> (IJavaProject) in order to work properly. Since the sample ecore editor doesn't
> know about this, the context won't be there and the types won't be resolvable.

Indeed, and so I have created an ActiveEditorXtextResourceSetBasedProjectProvider that falls back on locating the IProject of the active IEditorInput. (Very inelegantly this requires a Display.syncExec to access the main thread from a worker. Needs an EMF change to cache the IEditorInput in the EditingDomainResourceSet.) Anyway as a result I have a my JvmTypes displaying correctly in the Sample Ecore Editor, which hopefully enables me to use the same models in other modeling environments such as Acceleo.

[However next winge/suggestion, with 50 odd JVM types, I get 50 off extra java:/Objects/... resources. Perhaps these should use at least one level of package hierarchy so that only one java:/... REsource is contributed.]

Comment 4 Ed Willink

2010-09-29 04:37:04 EDT

(In reply to comment #3)
> (Very inelegantly this requires a
> Display.syncExec to access the main thread from a worker. Needs an EMF change
> to cache the IEditorInput in the EditingDomainResourceSet.)

Bug 326493 raised to support IProject access in EMF.

Comment 5 Sebastian Zarnekow

2010-10-05 08:03:00 EDT

*** Bug 273860 has been marked as a duplicate of this bug. ***

Comment 6 Ed Willink

2010-10-05 08:11:41 EDT

(In reply to comment #4)
> (In reply to comment #3)
> > (Very inelegantly this requires a
> > Display.syncExec to access the main thread from a worker. Needs an EMF change
> > to cache the IEditorInput in the EditingDomainResourceSet.)
> 
> Bug 326493 raised to support IProject access in EMF.

Ed Merks helpfully pointed out that the URI allows the resource and so the project to be located. No EMF change needed.

Comment 7 Moritz Eysholdt

2016-08-19 08:28:49 EDT

*** Bug 366992 has been marked as a duplicate of this bug. ***