Community
Participate
Working Groups
While investigating a Sample Ecore issue I found I was using an XtextResourceSet and so tried to see how I had corrupted the Sample Ecore Editor. I hadn't. There is now a dynamic test to use EcoreEditor Class<?> xtextResourceSetClass = CommonPlugin.loadClass("org.eclipse.xtext", "org.eclipse.xtext.resource.XtextResourceSet"); This seems wrong to me. It gives the impression that EMF is favouring Xtext. I thought the Eclipse philosophy was to be extensible with neutral extension points. XtextResourceSet represents a clear improvement when dealing with many resources. Perhaps it should be promoted to EMF as BigResourceSetImpl. classpath: URIs are really useful, but inconvenient because they only work sometimes. It would be good to promote this functionality to EMF too and ensure that next time an additional scheme can be added via an extension point.
Is something actually broken or you just don't like the design and would like it to conform to your expectations? These changes have to do with supporting Xcore models dynamically, i.e, we can have dynamic instances that refer to an Xcore-derived Ecore model. The editor must be able to load such resources but that's not possible without an Xtext resource set. Definitely EMF is "favoring" Xcore and whatever is needed to make it work. It's unfortunate that Xtext resources can't load in a normal resource set; one might complain about that design choice as well, especially given that much can be accomplished with adapters. I'm not sure how XtextResourceSet is a big improvement. Only the specialized resolver/normalizer (for classpath URIs) is fundamental; the rest could have been done with an adapter. And even the specialized URI converter could have bee added with a setURIConverter call.
I assume this isn't causing a problem that needs fixing but rather it's an observation about a design you consider less than ideal.
