Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mmt-dev] EmfUtil: content-type computation


As I wrote before three stages are needed

a) identify the most restrictive output meta-model EPackage
b) convert the EPackage to its content-type
c) create the resource by content type

As you noted step c) became generally available in the Ganymede release in June 2008. This left a) and b) as an overlooked application requirement.

Calling c) by itself with null or unspecifoed content type is useless since it requires telepathy to know the required content-type.

A transformation tool such as QVTo knows the output meta-model type, so it knows the EPackage so it can know the content-type.

It just requires the output algorithm to do this.

EmfUtil.createResource(URI uri, ResourceSet outResourceSet) is not necessarily the right place since it conatins all sorts of artefacts.

The algorithm should be earlier where only the output meta-models contribute to the decision.


        Ed Willink

On 19/06/2012 09:17, Uwe Ritzmann wrote:
Hi again,

I think you misunderstand my comments.
I cannot see where you are disagreeing with me.
I do not now understand what you really want.

If you want to continue this discussion, please start again and express
your self clearly.


          Ed Willink
I design a simple ecore model, generate all normal plugins.
In the model plugin I implement an additional ResourceFactory and Resource. In the plugin.xml I register a second content-type (based on text-content-type) and register the second ResourceFactory as content_parser.

Start runtime instance or deploy these plugins.
I associate a new extension "*.mytxt" to my content-type via
Menu Preferences>  General>  Content Types.

I write a QVTo transformation and try to launch it giving an output model URI with said new extension "platform:/someProject/model/output.mytxt".

Run the transformation and get XMI content in my output file.

[The symptom is the same when I - as plugin developer - already register "*.mytext" against the second content-type. As user that association is then already in the preference dialog and "(locked)". The result of the
QVTo run is exactly the same.]

As far as I can see from the browsable CVS at
the method ResourceSetImpl.createResource(uri,contentType) was made available 29.09.2007. This happens to fall together with the initial contribution of QVTo to Eclipse.
The initial version of EmfUtil does not use the new method.

On 30.01.2008 Sergey worked on resource creation in EmfUtil.
At that point in time he created EmfUtil.createResource(URI uri, ResourceSet outResourceSet).

It would be interesting to know, why he did not use the available
ResourceSetImpl.createResource(uri,UNSPECIFIED_CONTENT_TYPE) at
that point of time and added the "I better check the extensionToFactoryMap by myself" lines and decided to put the XMI fallback in there.

My assumption:
It would be more correct to call ResourceSetImpl.createResource(uri,UNSPECIFIED_CONTENT_TYPE) here and use and rely on the content-type computation abilities of the underlying platform.
Debugging my scenario I could see that this fixed my symptom partially.
The other part is an EMF issue, IMHO, and not QVTo-related.

Best Regards


Back to the top