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 
Hi again,
> Hi
> 
> 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.
> 
>      Regards
> 
>          Ed Willink

Symptom:
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.]

History:
As far as I can see from the browsable CVS at dev.eclipse.org
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

Uwe












-- 
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
Uwe Ritzmann              Uwe.Ritzmann@xxxxxx

Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Back to the top