Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 319811 - Dynamic Content Type Registry required
Summary: Dynamic Content Type Registry required
Status: CLOSED WONTFIX
Alias: None
Product: TMF
Classification: Modeling
Component: Xtext (show other bugs)
Version: 1.0.0   Edit
Hardware: PC Windows Vista
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-07-14 03:51 EDT by Ed Willink CLA
Modified: 2010-10-05 09:09 EDT (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Willink CLA 2010-07-14 03:51:20 EDT 
While trying to use an Xtext-edited file as a QVTo transformation source I encountered the following problem.

If all plugins are /resource/ the Xtext-edited file cannot be opened, since its content type is not registered.

If all plugins are both /plugin/ and /resource/ but the QVTo mappings reference /resource/ the transformation fails because the Xtext-edited file opens against the /plugin/ static EPackage whereas the QVTo transformation uses the /resource/ dynamic EPackage. No type matches. Silly me, but an easy to create and hard to debug problem.

To allow flexible development, it would be convenient to allow all (meta-)modeling activities to proceed in the current workspace. Xtext is the problem here. Somehow Xtext needs to make its content type to Resource Factory registration dynamically visible.

In the UMLX/QVTd/OCL Model Registry I was advocating a shared URI mapping capability, which is still needed since QVTo and other tools each having unique URI mapping definitions. It now appears that we require a shared dynamic content type registry; primarily for Xtext.
Comment 1 Moritz Eysholdt CLA 2010-07-14 03:56:23 EDT 
Xtext actually re-uses EMF's contenttype/fileextension to ResourceFactory mapping...
Comment 2 Ed Willink CLA 2010-07-14 04:09:51 EDT 
Exactly. EMF supports /plugin/ resource registration but not /resource/ registration. New mechanisms are needed to make things work in the current workspace.

EMF provides dynmaic/reflective Ecore to support /resource/ model content.
Tools provide diverse URI mapping to support /resource/ URI registration.
Nothing yet supports /resource/ content type registration.
Comment 3 Sebastian Zarnekow CLA 2010-10-05 09:09:33 EDT 
Xtext relies on compiled parsers etc. I cannot image that this could work with a dynamic registry and reasonable effort / complexity / benefit tradeoff? Please reopen if I missed the point.