Home » Modeling » EMF » Controlling behavior of ResourceSets
| Controlling behavior of ResourceSets [message #496703] |
Wed, 11 November 2009 04:24  |
 Derek Palma
Messages: 141
Registered: July 2009 |
Senior Member |
|
|
Hi,
We have implemented a repository which holds all kinds of content, but
wanted to have EMF support too. We have implemented an EPackage registry
which fronts this repository and also have a ResourceSet which allows us to
load/save to/from it using a special URI scheme.
Although it is no trouble using our own ResourceSet with our own code which
manipulates EMF artifacts, it would be great if our Repository could be used
by all componets which understand EMF resources, like Xtext, QVT, Xpand,
etc. However, there does not seem to be a way to cause ResourceSetImpls
instances to get initialized with the necessary URIHandlers, Adapters and
Package registry (well you could use Aspects but that's kind of nasty).
Does this mean the only way to cause a component to use a specifically
configured ResourceSetImpl is to explicity pass it to the componet and
expect it to only use that ResouceSet?
Is there any other approach where we can cause components to use our
ResourceSet without require specific code changes in them?
Thanks for any insight,
Derek
|
|
|
| Re: Controlling behavior of ResourceSets [message #496840 is a reply to message #496703] |
Wed, 11 November 2009 14:15  |
Ed Merks
Messages: 33217
Registered: July 2009 |
Senior Member |
|
|
Derek,
Comments below.
Derek Palma wrote:
> Hi,
>
> We have implemented a repository which holds all kinds of content, but
> wanted to have EMF support too. We have implemented an EPackage
> registry which fronts this repository and also have a ResourceSet
> which allows us to load/save to/from it using a special URI scheme.
>
> Although it is no trouble using our own ResourceSet with our own code
> which manipulates EMF artifacts, it would be great if our Repository
> could be used by all componets which understand EMF resources, like
> Xtext, QVT, Xpand, etc. However, there does not seem to be a way to
> cause ResourceSetImpls instances to get initialized with the necessary
> URIHandlers, Adapters and Package registry (well you could use Aspects
> but that's kind of nasty).
>
> Does this mean the only way to cause a component to use a specifically
> configured ResourceSetImpl is to explicity pass it to the componet and
> expect it to only use that ResouceSet?
>
> Is there any other approach where we can cause components to use our
> ResourceSet without require specific code changes in them?
We have https://bugs.eclipse.org/bugs/show_bug.cgi?id=286640 open, but
I'm extremely reluctant to allow folks to inject handlers in to the list
of all clients because the processing is done sequentially and would add
cost to all clients. However, I've been considering adding a single
handler similar to the EFS handler which acts like a map keyed on the
scheme so that the one handler can efficiently dispatch to an arbitrary
number of specialized schemes. Without this new support, you'd either
have to register with EFS or register a real live URL handler.
>
> Thanks for any insight,
> Derek
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Controlling behavior of ResourceSets [message #496977 is a reply to message #496840] |
Thu, 12 November 2009 02:10 |
Derek Palma
Messages: 141
Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
I took a look at EFSURIHandlerImpl and see what you mean. It's just a map
keyed by scheme. For repository like things scheme seems the only general
way since a repository holds all kinds of different artifacts. We have URIs
that look like:
repo:workspace1/vml/core/Core.vml?kind=file
I noticed that URI does not understand that Core.vml (an Xtext DSL file) has
an extension (.vml) so I was forced to register the scheme as a protocol in
the XtextResourceFactory in addition to the special URI handler. I am not
sure what the general implication of this is. Maybe there is a way to make
the URI more 'compatible'. However, it seems comply with the respective java
doc.
I was just trying to imagine how to build your preferred solution to just be
able to try it in my environment. It does not seem hard to make a map based
URI handler which calls the appropriate implementation for a given scheme.
The only issue is patching URIHandler.DEFAULT_HANDLERS. I suppose I must be
able to build EMF for this and generate the entire plug-in or is it possible
to insert it into the classpath (I am not familiar with this aspect of
Eclipse)
Derek
"Ed Merks" <Ed.Merks@gmail.com> wrote in message
news:hdegu1$krj$1@build.eclipse.org...
> Derek,
>
> Comments below.
>
> Derek Palma wrote:
>> Hi,
>>
>> We have implemented a repository which holds all kinds of content, but
>> wanted to have EMF support too. We have implemented an EPackage registry
>> which fronts this repository and also have a ResourceSet which allows us
>> to load/save to/from it using a special URI scheme.
>>
>> Although it is no trouble using our own ResourceSet with our own code
>> which manipulates EMF artifacts, it would be great if our Repository
>> could be used by all componets which understand EMF resources, like
>> Xtext, QVT, Xpand, etc. However, there does not seem to be a way to cause
>> ResourceSetImpls instances to get initialized with the necessary
>> URIHandlers, Adapters and Package registry (well you could use Aspects
>> but that's kind of nasty).
>>
>> Does this mean the only way to cause a component to use a specifically
>> configured ResourceSetImpl is to explicity pass it to the componet and
>> expect it to only use that ResouceSet?
>>
>> Is there any other approach where we can cause components to use our
>> ResourceSet without require specific code changes in them?
> We have https://bugs.eclipse.org/bugs/show_bug.cgi?id=286640 open, but I'm
> extremely reluctant to allow folks to inject handlers in to the list of
> all clients because the processing is done sequentially and would add cost
> to all clients. However, I've been considering adding a single handler
> similar to the EFS handler which acts like a map keyed on the scheme so
> that the one handler can efficiently dispatch to an arbitrary number of
> specialized schemes. Without this new support, you'd either have to
> register with EFS or register a real live URL handler.
>>
>> Thanks for any insight,
>> Derek
|
|
|
| Re: Controlling behavior of ResourceSets [message #497044 is a reply to message #496977] |
Thu, 12 November 2009 11:03 |
Ed Merks
Messages: 33217
Registered: July 2009 |
Senior Member |
|
|
Derek,
Comments below.
Derek Palma wrote:
> Hi Ed,
>
> I took a look at EFSURIHandlerImpl and see what you mean. It's just a
> map keyed by scheme. For repository like things scheme seems the only
> general way since a repository holds all kinds of different artifacts.
> We have URIs that look like:
>
> repo:workspace1/vml/core/Core.vml?kind=file
I'd generally highly recommend you ensure you're using a hierarchical
URI, i.e., the : be followed by at least one /.
>
> I noticed that URI does not understand that Core.vml (an Xtext DSL
> file) has an extension (.vml) so I was forced to register the scheme
> as a protocol in the XtextResourceFactory in addition to the special
> URI handler. I am not sure what the general implication of this is.
> Maybe there is a way to make the URI more 'compatible'. However, it
> seems comply with the respective java doc.
See the Javadoc/RFC about the distinction between hierarchical URIs and
opaque URIs. You're much better off with the former because the URI has
more structure that can be analyzed...
>
> I was just trying to imagine how to build your preferred solution to
> just be able to try it in my environment. It does not seem hard to
> make a map based URI handler which calls the appropriate
> implementation for a given scheme.
It's almost trivial. The most work is involved in the extension point
infrastructure and corresponding programmatic APIs, but even that's
relatively straight forward. If I were made of time, it would already be
done. Given the level of interest in this, I hope to be able to get it
done for 2.6...
> The only issue is patching URIHandler.DEFAULT_HANDLERS. I suppose I
> must be able to build EMF for this and generate the entire plug-in or
> is it possible to insert it into the classpath (I am not familiar with
> this aspect of Eclipse)
Within a given application, you can always modify the list of URI
handlers in the resource set's local URI converter.
>
> Derek
>
> "Ed Merks" <Ed.Merks@gmail.com> wrote in message
> news:hdegu1$krj$1@build.eclipse.org...
>> Derek,
>>
>> Comments below.
>>
>> Derek Palma wrote:
>>> Hi,
>>>
>>> We have implemented a repository which holds all kinds of content,
>>> but wanted to have EMF support too. We have implemented an EPackage
>>> registry which fronts this repository and also have a ResourceSet
>>> which allows us to load/save to/from it using a special URI scheme.
>>>
>>> Although it is no trouble using our own ResourceSet with our own
>>> code which manipulates EMF artifacts, it would be great if our
>>> Repository could be used by all componets which understand EMF
>>> resources, like Xtext, QVT, Xpand, etc. However, there does not seem
>>> to be a way to cause ResourceSetImpls instances to get initialized
>>> with the necessary URIHandlers, Adapters and Package registry (well
>>> you could use Aspects but that's kind of nasty).
>>>
>>> Does this mean the only way to cause a component to use a
>>> specifically configured ResourceSetImpl is to explicity pass it to
>>> the componet and expect it to only use that ResouceSet?
>>>
>>> Is there any other approach where we can cause components to use our
>>> ResourceSet without require specific code changes in them?
>> We have https://bugs.eclipse.org/bugs/show_bug.cgi?id=286640 open,
>> but I'm extremely reluctant to allow folks to inject handlers in to
>> the list of all clients because the processing is done sequentially
>> and would add cost to all clients. However, I've been considering
>> adding a single handler similar to the EFS handler which acts like a
>> map keyed on the scheme so that the one handler can efficiently
>> dispatch to an arbitrary number of specialized schemes. Without this
>> new support, you'd either have to register with EFS or register a
>> real live URL handler.
>>>
>>> Thanks for any insight,
>>> Derek
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Tue Sep 24 13:23:44 GMT 2024
Powered by FUDForum. Page generated in 0.02494 seconds |
] 
Search
Help
Register
Login
Home
