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

Bug 318548

Summary:	Supporting URIs like http://www.eclipse.org/emf/2002/Ecore
Product:	[Modeling] TMF	Reporter:	Hallvard Traetteberg <hal>
Component:	Xtext	Assignee:	Project Inbox <tmf.xtext-inbox>
Status:	CLOSED WORKSFORME	QA Contact:
Severity:	normal
Priority:	P3	CC:	Andy.Carpenter, sven.efftinge
Version:	unspecified	Flags:	sven.efftinge: indigo+
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:

Description Hallvard Traetteberg

2010-07-01 03:14:37 EDT

In my grammar I allow importing various kinds of models:
- Ecore models, both specified using URIs like http://www.eclipse.org/emf/2002/Ecore, and URIs ending in .ecore
- xmi files, typically dynamic instances
- other files with extensions

The .ecore variant is already bound to EcoreResourceServiceProviderImpl, and I want to allow the http-based one, like Ecore's own URI. Other URIs should be handled by a custom one. It seems natural to use a wildcard (*) bound to the custom one, and to use a more specific one for the http-case.

The first problem is that I cannot specify a null (non-existing) extension using the extension_resourceServiceProvider extension point. The alternative is to use the protocol. This works for my imports (but see bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=318547), but it strangely enough gives lots of error output concerning archive URIs, e.g.
ERROR org.eclipse.xtext.builder.builderState.ResourceDescriptionsUpdater  - Error loading resource from: archive:file:/System/...

The most natural fix (for me at least) would be to allow specifying an extension for the null case, e.g. using "" or "/" (opposite of *).

Comment 1 Sven Efftinge

2010-07-01 12:57:26 EDT

I didn't understand what you want to accomplish, but the resource service provider registry is used by the builder to determine which resources to index and to build. We need to be very selective with what files the builder indexes. It is not an option to register something responsible for everything. Also using the content provider (although support) should not be used, since it is very slow.

What functionality shall to pick up an IResourceServiceProvider for an EPackage's URI in your case? What exactly do you want to do?

Comment 2 Hallvard Traetteberg

2010-07-01 17:05:58 EDT

(In reply to comment #1)
> 
> What functionality shall to pick up an IResourceServiceProvider for an
> EPackage's URI in your case? What exactly do you want to do?

Maybe I've misunderstood the role of IResourceServiceProvider. If I understand correctly, there must be a IResourceServiceProvider for each kind of file that the user (of the DSL) may import.

I want to support the import of various kinds of models, both Ecore models and instance data. Hence, I have grammar rules that set the importURI attribute to the URI of the model/file I want to import. These URIs will both be the http://.../Ecore kind and URIs ending on a file with file extension.

In principle, there is no limit to which files the user can import (as long as they are xmi-encoded). If this means all these will be indexed, it would be nice to find a way to limit indexing, while allowing import.

Comment 3 Sven Efftinge

2010-07-02 03:16:26 EDT

As long as you(In reply to comment #2)
> (In reply to comment #1)
> > 
> > What functionality shall to pick up an IResourceServiceProvider for an
> > EPackage's URI in your case? What exactly do you want to do?
> 
> Maybe I've misunderstood the role of IResourceServiceProvider. If I understand
> correctly, there must be a IResourceServiceProvider for each kind of file that
> the user (of the DSL) may import.

Yes, for the default case this is true.

> I want to support the import of various kinds of models, both Ecore models and
> instance data. Hence, I have grammar rules that set the importURI attribute to
> the URI of the model/file I want to import. These URIs will both be the
> http://.../Ecore kind and URIs ending on a file with file extension.

You'll have to make a corresponding IResourceDescription available for each URI you want
to be able to use. The general hook would indeed be to implement and register a IResourceServiceProvider for each language you want to refer to.
However as I said this would make those models being indexed.
If that is not a problem you could register an IResourceServiceProvider for the 'xmi' extension.

Unfortunately you won't be able to define another one for *.ecore in order to make it export the ecore files by the nsURI as well. 
What you could do is having your own IResourceDescriptions which delegates to the global one, but
adds IResourceDescriptions for ecore models. 
Another solution would be to use a mapping and replace any nsURIs with corresponding resource URIs in the IScopeProvider.

> In principle, there is no limit to which files the user can import (as long as
> they are xmi-encoded). If this means all these will be indexed, it would be
> nice to find a way to limit indexing, while allowing import.

Yes, maybe we should add an explicit method 'isIndexed(URI)' or similar to IResourceServiceProvider.

Comment 4 Hallvard Traetteberg

2010-07-02 03:43:19 EDT

> You'll have to make a corresponding IResourceDescription available for each URI
> you want to be able to use. The general hook would indeed be to implement and register a
> IResourceServiceProvider for each language you want to refer to.
> However as I said this would make those models being indexed.
> If that is not a problem you could register an IResourceServiceProvider for the
> 'xmi' extension.

So, although I didn't think of indexing, my understanding was basically correct.

> Unfortunately you won't be able to define another one for *.ecore in order to
> make it export the ecore files by the nsURI as well.

I don't need a custom one for this case, I just want to support the nsURI variant and reuse the existing EcoreResourceServiceProviderImpl.

> Another solution would be to use a mapping and replace any nsURIs with
> corresponding resource URIs in the IScopeProvider.

Wouldn't this load a separate (Ecore) model instance, instead of using the registered (static) EPackage? It's important to link to the same instances I get when using EcorePackage.eINSTANCE.getEString(), etc.

> Yes, maybe we should add an explicit method 'isIndexed(URI)' or similar to
> IResourceServiceProvider.

And/or add an attribute in the extension point telling that the declared IResourceServiceProvider should not allow/trigger indexing.

In addition, I still think there's a need for supporting nsURIs that don't include a file extension.

Comment 5 Sven Efftinge

2012-11-14 05:09:10 EST

if you want to refer to some element in a physical file via http URI, register a ResourceServiceProvider for the file extension and export EObjectDescriptions with the respective HTTP URI as the name.