| [QVTO] Restrictions on EMF resource types [message #482271] |
Tue, 25 August 2009 23:47  |
 Alex Mising name
Messages: 51
Registered: August 2009 |
Member |
|
|
In general QVTO runtime likely does not care about what kinds of EMF resources are used for models, as long as it can access objects in the EMF resource. However, currently the QVTO launch validation appears to restrict these resources to several types - those that are file/platform/archive based, or those that can be opened via URL.openConnection().
While this likely covers the most common types, it appears to miss out on the flexibility and extendability of the EMF resource framework. For example, custom protocol types can be defined for custom EMF resource implementations - and QVT unfortunately won't accept these as valid models, even though one could easily open them in EMF model editors or manipulate them via EMF APIs.
We've hit this with our own custom implementations of EMF resources, but I am thinking something like CDO should be a good example. If I remember correctly they use cdo:// in their resource URIs, which likely won't be accepted by QVTO.
There may be ways to work around this issue - e.g. using EFS to surface these as platform:// resources, implementing custom Java protocol handlers that would enable URL.openConnection(), using proxy files containing pointers to real EMF resources etc. - but directly supporting anything that EMF supports seems to be the best course of action.
Somewhat related: it has been mentioned in this forum that there are plans to support standalone QVTO execution - BTW, is there a bugzilla for this? - and this would likely require some changes to how model resources are handled, but I am not sure if the general issue of EMF resource types is expected to be handled by that activity ...
Alex
[Updated on: Tue, 25 August 2009 23:50] Report message to a moderator |
|
|
| Re: [QVTO] Restrictions on EMF resource types [message #482388 is a reply to message #482271] |
Wed, 26 August 2009 11:56  |
Sergey Boyko
Messages: 171
Registered: July 2009 |
Senior Member |
|
|
Hi Alex ,
Some replies are in-lined, below
Regards,
Sergey
Alex wrote:
> In general QVTO runtime likely does not care about what kinds of EMF
> resources are used for models, as long as it can access objects in the
> EMF resource. However, currently the QVTO launch validation appears to
> restrict these resources to several types - those that are
> file/platform/archive based, or those that can be opened via
> URI.openConnection().
>
> While this likely covers the most common types, it appears to miss out
> on the flexibility and extendability of the EMF resource framework. For
> example, custom protocol types can be defined for custom EMF resource
> implementations - and QVT unfortunately won't accept these as valid
> models, even though one could easily open them in EMF model editors or
> manipulate them via EMF APIs.
>
> We've hit this with our own custom implementations of EMF resources, but
> I am thinking something like CDO should be a good example. If I remember
> correctly they use cdo:// in their resource URIs, which likely won't be
> accepted by QVTO.
I got your point.
Actually we have non-EMF models that are wrapped with custom Resource
implementation and specific protocol defined like follows:
<extension point="org.eclipse.emf.ecore.protocol_parser">
<parser
class="com.xxx.CustomResourceFactory"
protocolName="xxx"/>
</extension>
But our case is that these models are input-only. And qvto launch
configuration allows to select them for such kind.
Agree that existing excessive checking for [inout] and [out] parameter's
types should be revised as well.
>
> There may be ways to work around this issue - e.g. using EFS to surface
> these as platform: resources, implementing custom Java protocol handlers
> that would enable URL.openConnection(), using proxy files containing
> pointers to real EMF resources etc, - but directly supporting anything
> that EMF supports seems to be the best course of action.
>
> Somewhat related: it has been mentioned in this forum that there are
> plans to support standalone QVTO execution - BTW, is there a bugzilla
> for this? - and this would likely require some changes to how model
> resources are handled, but I am not sure if the general issue of EMF
> resource types is expected to be handled by that activity ...
Just created: https://bugs.eclipse.org/bugs/show_bug.cgi?id=287685
>
> Alex
|
|
|
Powered by
FUDForum. Page generated in 0.03252 seconds
] 
Search
Help
Register
Login
Home
