Home » Modeling » EMF » Overriding the default resource factory for .ecore files
| Overriding the default resource factory for .ecore files [message #428518] |
Tue, 24 March 2009 15:08  |
 Mirko Seifert
Messages: 31
Registered: July 2009 |
Member |
|
|
Hi,
I want to register a resource factory for .ecore files that loads Ecore
files represented in a text syntax rather than XMI.
I did the following:
<extension point="org.eclipse.emf.ecore.content_parser">
<parser class="org.company.CustomizedEcoreResourceFactory"
contentTypeIdentifier="org.eclipse.emf.ecore.textual">
</parser>
</extension>
<extension point="org.eclipse.core.contenttype.contentTypes">
<file-association content-type="org.ecore.textual"
file-extensions="ecore">
</file-association>
</extension>
<extension point="org.eclipse.core.runtime.contentTypes" id="someID">
<content-type id="org.eclipse.emf.ecore.textual"
name="Ecore Textual Syntax"
file-extensions="ecore">
<describer class="org.company.TextualEcoreContentDescriber"/>
</content-type>
</extension>
However, the default resource factory (defined in plug-in
org.eclipse.emf.ecore.xmi) is always preferred, because extension
parsers have a higher priority than content parsers.
As a result, my (textual) Ecore files are not loaded using my resource
factory (CustomizedEcoreResourceFactory), but the default factory
(EcoreResourceFactoryImpl), which fails.
If I manually de-register the default factory, the whole thing works,
but this is somewhat ugly:
Registry registry = Resource.Factory.Registry.INSTANCE;
registry.getExtensionToFactoryMap().remove("ecore");
Is there a way to do this more clever?
Cheers,
Mirko
P.S. I've read http://www.eclipsezone.com/eclipse/forums/t107605.html
but this is not a solution, because I do not have access to the editing
domain that loads my textual ecore models.
|
|
|
| Re: Overriding the default resource factory for .ecore files [message #428523 is a reply to message #428518] |
Tue, 24 March 2009 15:25  |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Mirko,
Comments below.
Mirko Seifert wrote:
> Hi,
>
> I want to register a resource factory for .ecore files that loads
> Ecore files represented in a text syntax rather than XMI.
Like Emphatic...
>
>
> I did the following:
>
>
> <extension point="org.eclipse.emf.ecore.content_parser">
> <parser class="org.company.CustomizedEcoreResourceFactory"
> contentTypeIdentifier="org.eclipse.emf.ecore.textual">
> </parser>
> </extension>
>
> <extension point="org.eclipse.core.contenttype.contentTypes">
> <file-association content-type="org.ecore.textual"
> file-extensions="ecore">
> </file-association>
> </extension>
Reusing the same extension seems like a bad idea...
>
> <extension point="org.eclipse.core.runtime.contentTypes" id="someID">
> <content-type id="org.eclipse.emf.ecore.textual"
> name="Ecore Textual Syntax"
> file-extensions="ecore">
> <describer class="org.company.TextualEcoreContentDescriber"/>
> </content-type>
> </extension>
>
>
> However, the default resource factory (defined in plug-in
> org.eclipse.emf.ecore.xmi) is always preferred, because extension
> parsers have a higher priority than content parsers.
Yes. That was to avoid having content type registrations affect all
clients who were previously getting along fine without them.
>
> As a result, my (textual) Ecore files are not loaded using my resource
> factory (CustomizedEcoreResourceFactory), but the default factory
> (EcoreResourceFactoryImpl), which fails.
> If I manually de-register the default factory, the whole thing works,
> but this is somewhat ugly:
>
> Registry registry = Resource.Factory.Registry.INSTANCE;
> registry.getExtensionToFactoryMap().remove("ecore");
Don't do that!
>
>
> Is there a way to do this more clever?
Here's a good technique:
resourceSet.getResourceFactoryRegistry.getContentTypeToFacto ryMap().putAll(Resource.Factory.Registry.INSTANCE.getContent TypeToFactoryMap());
Now all content type registrations will be considered first in this
resource set. I think reusing the same extension for a different format
is probably a bad idea though....
>
> Cheers,
>
> Mirko
>
> P.S. I've read http://www.eclipsezone.com/eclipse/forums/t107605.html
> but this is not a solution, because I do not have access to the
> editing domain that loads my textual ecore models.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Overriding the default resource factory for .ecore files [message #428528 is a reply to message #428523] |
Tue, 24 March 2009 15:54 |
Mirko Seifert
Messages: 31
Registered: July 2009 |
Member |
|
|
Hi Ed,
Ed Merks wrote:
> Mirko,
>
> Comments below.
>
> Mirko Seifert wrote:
>> Hi,
>>
>> I want to register a resource factory for .ecore files that loads
>> Ecore files represented in a text syntax rather than XMI.
> Like Emphatic...
Exactly. They use a different extension and let users convert between
the two formats (XMI vs. text), which is time-consuming when metamodels
change a lot.
>> I did the following:
>>
>>
>> <extension point="org.eclipse.emf.ecore.content_parser">
>> <parser class="org.company.CustomizedEcoreResourceFactory"
>> contentTypeIdentifier="org.eclipse.emf.ecore.textual">
>> </parser>
>> </extension>
>>
>> <extension point="org.eclipse.core.contenttype.contentTypes">
>> <file-association content-type="org.ecore.textual"
>> file-extensions="ecore">
>> </file-association>
>> </extension>
> Reusing the same extension seems like a bad idea...
I know, but using a different extension (e.g. 'tecore') does not work
because I can't create generator models for such files. As generating
code is the most usual task that is performed on the ecore models, this
is desperately needed.
>> <extension point="org.eclipse.core.runtime.contentTypes" id="someID">
>> <content-type id="org.eclipse.emf.ecore.textual"
>> name="Ecore Textual Syntax"
>> file-extensions="ecore">
>> <describer class="org.company.TextualEcoreContentDescriber"/>
>> </content-type>
>> </extension>
>>
>>
>> However, the default resource factory (defined in plug-in
>> org.eclipse.emf.ecore.xmi) is always preferred, because extension
>> parsers have a higher priority than content parsers.
> Yes. That was to avoid having content type registrations affect all
> clients who were previously getting along fine without them.
>>
>> As a result, my (textual) Ecore files are not loaded using my resource
>> factory (CustomizedEcoreResourceFactory), but the default factory
>> (EcoreResourceFactoryImpl), which fails.
>> If I manually de-register the default factory, the whole thing works,
>> but this is somewhat ugly:
>>
>> Registry registry = Resource.Factory.Registry.INSTANCE;
>> registry.getExtensionToFactoryMap().remove("ecore");
> Don't do that!
>>
>>
>> Is there a way to do this more clever?
> Here's a good technique:
>
>
> resourceSet.getResourceFactoryRegistry.getContentTypeToFacto ryMap().putAll(Resource.Factory.Registry.INSTANCE.getContent TypeToFactoryMap());
Unfortunately I do not have access to the resourceSet. It is hidden
somewhere in the EMF code generation classes.
> Now all content type registrations will be considered first in this
> resource set. I think reusing the same extension for a different format
> is probably a bad idea though....
Do you have any other idea/comment?
Thanks,
Mirko
|
|
|
| Re: Overriding the default resource factory for .ecore files [message #428531 is a reply to message #428528] |
Tue, 24 March 2009 16:47 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Mirko,
comments below.
Mirko Seifert wrote:
> Hi Ed,
>
> Ed Merks wrote:
>> Mirko,
>>
>> Comments below.
>>
>> Mirko Seifert wrote:
>>> Hi,
>>>
>>> I want to register a resource factory for .ecore files that loads
>>> Ecore files represented in a text syntax rather than XMI.
>> Like Emphatic...
>
> Exactly. They use a different extension and let users convert between
> the two formats (XMI vs. text), which is time-consuming when
> metamodels change a lot.
Yes, it's a pain to sync them manually.
>
>>> I did the following:
>>>
>>>
>>> <extension point="org.eclipse.emf.ecore.content_parser">
>>> <parser class="org.company.CustomizedEcoreResourceFactory"
>>> contentTypeIdentifier="org.eclipse.emf.ecore.textual">
>>> </parser>
>>> </extension>
>>>
>>> <extension point="org.eclipse.core.contenttype.contentTypes">
>>> <file-association content-type="org.ecore.textual"
>>> file-extensions="ecore">
>>> </file-association>
>>> </extension>
>> Reusing the same extension seems like a bad idea...
>
> I know, but using a different extension (e.g. 'tecore') does not work
> because I can't create generator models for such files.
I know the file dialog makes it hard and the workspace dialog only shows
matching extension, but I'm pretty sure you could enter a URI with any
extension...
> As generating code is the most usual task that is performed on the
> ecore models, this is desperately needed.
It's worth trying to enter URIs with different extension manually and
see how much of all this will "just works". Maybe all of it.
>
>>> <extension point="org.eclipse.core.runtime.contentTypes" id="someID">
>>> <content-type id="org.eclipse.emf.ecore.textual"
>>> name="Ecore Textual Syntax"
>>> file-extensions="ecore">
>>> <describer class="org.company.TextualEcoreContentDescriber"/>
>>> </content-type>
>>> </extension>
>>>
>>>
>>> However, the default resource factory (defined in plug-in
>>> org.eclipse.emf.ecore.xmi) is always preferred, because extension
>>> parsers have a higher priority than content parsers.
>> Yes. That was to avoid having content type registrations affect all
>> clients who were previously getting along fine without them.
>>>
>>> As a result, my (textual) Ecore files are not loaded using my
>>> resource factory (CustomizedEcoreResourceFactory), but the default
>>> factory (EcoreResourceFactoryImpl), which fails.
>>> If I manually de-register the default factory, the whole thing
>>> works, but this is somewhat ugly:
>>>
>>> Registry registry = Resource.Factory.Registry.INSTANCE;
>>> registry.getExtensionToFactoryMap().remove("ecore");
>> Don't do that!
>>>
>>>
>>> Is there a way to do this more clever?
>> Here's a good technique:
>>
>>
>> resourceSet.getResourceFactoryRegistry.getContentTypeToFacto ryMap().putAll(Resource.Factory.Registry.INSTANCE.getContent TypeToFactoryMap());
>
>
> Unfortunately I do not have access to the resourceSet. It is hidden
> somewhere in the EMF code generation classes.
I see that now.
>
>> Now all content type registrations will be considered first in this
>> resource set. I think reusing the same extension for a different
>> format is probably a bad idea though....
>
> Do you have any other idea/comment?
I think it's mostly a problem that the dialogs are too smart about
encouraging the use of a known extension. Try it and let me know...
>
> Thanks,
>
> Mirko
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Overriding the default resource factory for .ecore files [message #428600 is a reply to message #428531] |
Wed, 25 March 2009 10:29 |
Mirko Seifert
Messages: 31
Registered: July 2009 |
Member |
|
|
Hi Ed,
as it seems that my problem boils down to getting the EMF generator
model wizard accept files other than '.ecore' I'll shorten the previous
discussion a little.
I followed your suggestion, used a different extension (.tecore) and
directly entered a URI to my textual Ecore model
(/projectname/new.tecore), which is then indeed loaded by the wizard.
However, after clicking "Next" the wizard correctly shows the packages
defined in new.tecore, but complains "The Ecore model file name for
package 'someEPackageName' must end in '.ecore' or '.emof'". So I can't
continue.
Maybe there is a way to tell the wizard to accept other extensions?
Cheers,
Mirko
Ed Merks schrieb:
> Mirko,
>
> comments below.
>
> Mirko Seifert wrote:
>> Hi Ed,
>>
>> Ed Merks wrote:
>>> Mirko,
>>>
>>> Comments below.
>>>
>>> Mirko Seifert wrote:
>>>> Hi,
>>>>
>>>> I want to register a resource factory for .ecore files that loads
>>>> Ecore files represented in a text syntax rather than XMI.
>>> Reusing the same extension seems like a bad idea...
>> I know, but using a different extension (e.g. 'tecore') does not work
>> because I can't create generator models for such files.
> I know the file dialog makes it hard and the workspace dialog only shows
> matching extension, but I'm pretty sure you could enter a URI with any
> extension...
>> As generating code is the most usual task that is performed on the
>> ecore models, this is desperately needed.
> It's worth trying to enter URIs with different extension manually and
> see how much of all this will "just works". Maybe all of it.
>>> Now all content type registrations will be considered first in this
>>> resource set. I think reusing the same extension for a different
>>> format is probably a bad idea though....
>>
>> Do you have any other idea/comment?
> I think it's mostly a problem that the dialogs are too smart about
> encouraging the use of a known extension. Try it and let me know...
>>
>> Thanks,
>>
>> Mirko
|
|
|
| Re: Overriding the default resource factory for .ecore files [message #428607 is a reply to message #428600] |
Wed, 25 March 2009 11:58 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Mirko,
We probably should be more forgiving but I suppose if we wanted to get
fancy, we'd have an extension point that would allow one to specify
additional extensions for resource types that will transparently be
treated as containing Ecore models during import. I'd certainly be
willing to entertain that, but I'll need help with verifying that the
design works for you, and I'm not at my most productive best these days
for personal reasons. Are you developing against 2.5. Will this help?
Mirko Seifert wrote:
> Hi Ed,
>
> as it seems that my problem boils down to getting the EMF generator
> model wizard accept files other than '.ecore' I'll shorten the
> previous discussion a little.
>
> I followed your suggestion, used a different extension (.tecore) and
> directly entered a URI to my textual Ecore model
> (/projectname/new.tecore), which is then indeed loaded by the wizard.
> However, after clicking "Next" the wizard correctly shows the packages
> defined in new.tecore, but complains "The Ecore model file name for
> package 'someEPackageName' must end in '.ecore' or '.emof'". So I
> can't continue.
>
> Maybe there is a way to tell the wizard to accept other extensions?
>
> Cheers,
>
> Mirko
>
>
> Ed Merks schrieb:
>> Mirko,
>>
>> comments below.
>>
>> Mirko Seifert wrote:
>>> Hi Ed,
>>>
>>> Ed Merks wrote:
>>>> Mirko,
>>>>
>>>> Comments below.
>>>>
>>>> Mirko Seifert wrote:
>>>>> Hi,
>>>>>
>>>>> I want to register a resource factory for .ecore files that loads
>>>>> Ecore files represented in a text syntax rather than XMI.
>>>> Reusing the same extension seems like a bad idea...
>>> I know, but using a different extension (e.g. 'tecore') does not
>>> work because I can't create generator models for such files.
>> I know the file dialog makes it hard and the workspace dialog only
>> shows matching extension, but I'm pretty sure you could enter a URI
>> with any extension...
>>> As generating code is the most usual task that is performed on the
>>> ecore models, this is desperately needed.
>> It's worth trying to enter URIs with different extension manually and
>> see how much of all this will "just works". Maybe all of it.
>>>> Now all content type registrations will be considered first in this
>>>> resource set. I think reusing the same extension for a different
>>>> format is probably a bad idea though....
>>>
>>> Do you have any other idea/comment?
>> I think it's mostly a problem that the dialogs are too smart about
>> encouraging the use of a known extension. Try it and let me know...
>>>
>>> Thanks,
>>>
>>> Mirko
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Overriding the default resource factory for .ecore files [message #428648 is a reply to message #428607] |
Wed, 25 March 2009 20:23 |
Mirko Seifert
Messages: 31
Registered: July 2009 |
Member |
|
|
Hi Ed,
I think adding such an extension point could certainly solve the problem
at hand. I currently build against EMF 2.4.2, but could use 2.5 as well.
I'm also willing to verify and support the design of the feature.
However, before we start to do so I'd like to go back one step and bring
up the discussion about the extension parsers and the content parsers
again. I'm sorry, because you might be tired of that discussion, but I
just want to understand this more deeply:
I'm aware that you do not want to change the priorities to make sure
existing clients still get the behavior they expect. I agree with that.
But, for a second let's suppose the EcoreResourceFactoryImpl would not
be registered as extension parser, but as content parser. What are the
implications?
I think functionally it would be the same, because all Ecore files saved
as XMI could still be loaded. Non-functionally (in terms of performance)
there would obviously be a difference, because the content parser needs
to have a look into every '.ecore' file to decide whether it is an XMI
file or not. However, this happens only when files change and it
requires looking at the first (four?) bytes in the file only (to check
whether the XMI header is there). The question is, whether this is
really significant for a reasonable number of .ecore files in a
workspace. Am I missing something here?
Since EMF provides this powerful content parsing extension point that
allows to save different content types in files with the same extension
then why should we not make use of it for ecore itself.
Again, sorry for bringing this up again, but I want to make sure that we
are not adding something here that solves only the (small) problem with
the generator model wizard, but is actually about something else. Other
tools might also ask for .ecore files and face the same problem.
Cheers,
Mirko
Ed Merks wrote:
> Mirko,
>
> We probably should be more forgiving but I suppose if we wanted to get
> fancy, we'd have an extension point that would allow one to specify
> additional extensions for resource types that will transparently be
> treated as containing Ecore models during import. I'd certainly be
> willing to entertain that, but I'll need help with verifying that the
> design works for you, and I'm not at my most productive best these days
> for personal reasons. Are you developing against 2.5. Will this help?
>
>
> Mirko Seifert wrote:
>> Hi Ed,
>>
>> as it seems that my problem boils down to getting the EMF generator
>> model wizard accept files other than '.ecore' I'll shorten the
>> previous discussion a little.
>>
>> I followed your suggestion, used a different extension (.tecore) and
>> directly entered a URI to my textual Ecore model
>> (/projectname/new.tecore), which is then indeed loaded by the wizard.
>> However, after clicking "Next" the wizard correctly shows the packages
>> defined in new.tecore, but complains "The Ecore model file name for
>> package 'someEPackageName' must end in '.ecore' or '.emof'". So I
>> can't continue.
>>
>> Maybe there is a way to tell the wizard to accept other extensions?
>>
>> Cheers,
>>
>> Mirko
>>
>>
>> Ed Merks schrieb:
>>> Mirko,
>>>
>>> comments below.
>>>
>>> Mirko Seifert wrote:
>>>> Hi Ed,
>>>>
>>>> Ed Merks wrote:
>>>>> Mirko,
>>>>>
>>>>> Comments below.
>>>>>
>>>>> Mirko Seifert wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I want to register a resource factory for .ecore files that loads
>>>>>> Ecore files represented in a text syntax rather than XMI.
>>>>> Reusing the same extension seems like a bad idea...
>>>> I know, but using a different extension (e.g. 'tecore') does not
>>>> work because I can't create generator models for such files.
>>> I know the file dialog makes it hard and the workspace dialog only
>>> shows matching extension, but I'm pretty sure you could enter a URI
>>> with any extension...
>>>> As generating code is the most usual task that is performed on the
>>>> ecore models, this is desperately needed.
>>> It's worth trying to enter URIs with different extension manually and
>>> see how much of all this will "just works". Maybe all of it.
>>>>> Now all content type registrations will be considered first in this
>>>>> resource set. I think reusing the same extension for a different
>>>>> format is probably a bad idea though....
>>>>
>>>> Do you have any other idea/comment?
>>> I think it's mostly a problem that the dialogs are too smart about
>>> encouraging the use of a known extension. Try it and let me know...
>>>>
>>>> Thanks,
>>>>
>>>> Mirko
|
|
|
| Re: Overriding the default resource factory for .ecore files [message #428656 is a reply to message #428648] |
Wed, 25 March 2009 23:39 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Mirko,
Comments below.
Mirko Seifert wrote:
> Hi Ed,
>
> I think adding such an extension point could certainly solve the
> problem at hand. I currently build against EMF 2.4.2, but could use
> 2.5 as well. I'm also willing to verify and support the design of the
> feature.
>
> However, before we start to do so I'd like to go back one step and
> bring up the discussion about the extension parsers and the content
> parsers again. I'm sorry, because you might be tired of that
> discussion, but I just want to understand this more deeply:
>
> I'm aware that you do not want to change the priorities to make sure
> existing clients still get the behavior they expect. I agree with that.
>
> But, for a second let's suppose the EcoreResourceFactoryImpl would not
> be registered as extension parser, but as content parser. What are the
> implications?
The file has to be opened and analyzed to be sure that it's really XML
content with a root element from the Ecore namespace; and expense not
incurred in the past.
>
> I think functionally it would be the same, because all Ecore files
> saved as XMI could still be loaded.
People care about more than function, they also care about performance.
> Non-functionally (in terms of performance) there would obviously be a
> difference, because the content parser needs to have a look into every
> '.ecore' file to decide whether it is an XMI file or not.
Indeed.
> However, this happens only when files change and it requires looking
> at the first (four?) bytes in the file only (to check whether the XMI
> header is there).
No, it has to look at the namespace of the root element. Outside of the
workspace, this information isn't cached and certainly isn't free to
compute.
> The question is, whether this is really significant for a reasonable
> number of .ecore files in a workspace. Am I missing something here?
It's indeed a question and I'll assure you that it's significant
compared to syntactically matching an extension on a URI. IO verses a
simple syntactic check...
>
> Since EMF provides this powerful content parsing extension point that
> allows to save different content types in files with the same
> extension then why should we not make use of it for ecore itself.
From a content type point fo view, one could imagine specifying Ecore
content, but the hiearchy for text content verses XML content would be
parallel and content type hierarchies don't support multiple inheritance...
>
> Again, sorry for bringing this up again, but I want to make sure that
> we are not adding something here that solves only the (small) problem
> with the generator model wizard, but is actually about something else.
> Other tools might also ask for .ecore files and face the same problem.
Content types are all fine and cool, but I'm always taken aback by how
poorly the overall concepts are considered. Imagine 1000 parsers all
looking at the same *.xml file to decide if it's content they
recognized. Each one duplicates an full XML parse of the start of the
file. Does that really scale well? I imagine not.
>
> Cheers,
>
> Mirko
>
>
> Ed Merks wrote:
>> Mirko,
>>
>> We probably should be more forgiving but I suppose if we wanted to
>> get fancy, we'd have an extension point that would allow one to
>> specify additional extensions for resource types that will
>> transparently be treated as containing Ecore models during import.
>> I'd certainly be willing to entertain that, but I'll need help with
>> verifying that the design works for you, and I'm not at my most
>> productive best these days for personal reasons. Are you developing
>> against 2.5. Will this help?
>>
>>
>> Mirko Seifert wrote:
>>> Hi Ed,
>>>
>>> as it seems that my problem boils down to getting the EMF generator
>>> model wizard accept files other than '.ecore' I'll shorten the
>>> previous discussion a little.
>>>
>>> I followed your suggestion, used a different extension (.tecore) and
>>> directly entered a URI to my textual Ecore model
>>> (/projectname/new.tecore), which is then indeed loaded by the
>>> wizard. However, after clicking "Next" the wizard correctly shows
>>> the packages defined in new.tecore, but complains "The Ecore model
>>> file name for package 'someEPackageName' must end in '.ecore' or
>>> '.emof'". So I can't continue.
>>>
>>> Maybe there is a way to tell the wizard to accept other extensions?
>>>
>>> Cheers,
>>>
>>> Mirko
>>>
>>>
>>> Ed Merks schrieb:
>>>> Mirko,
>>>>
>>>> comments below.
>>>>
>>>> Mirko Seifert wrote:
>>>>> Hi Ed,
>>>>>
>>>>> Ed Merks wrote:
>>>>>> Mirko,
>>>>>>
>>>>>> Comments below.
>>>>>>
>>>>>> Mirko Seifert wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I want to register a resource factory for .ecore files that
>>>>>>> loads Ecore files represented in a text syntax rather than XMI.
>>>>>> Reusing the same extension seems like a bad idea...
>>>>> I know, but using a different extension (e.g. 'tecore') does not
>>>>> work because I can't create generator models for such files.
>>>> I know the file dialog makes it hard and the workspace dialog only
>>>> shows matching extension, but I'm pretty sure you could enter a URI
>>>> with any extension...
>>>>> As generating code is the most usual task that is performed on the
>>>>> ecore models, this is desperately needed.
>>>> It's worth trying to enter URIs with different extension manually
>>>> and see how much of all this will "just works". Maybe all of it.
>>>>>> Now all content type registrations will be considered first in
>>>>>> this resource set. I think reusing the same extension for a
>>>>>> different format is probably a bad idea though....
>>>>>
>>>>> Do you have any other idea/comment?
>>>> I think it's mostly a problem that the dialogs are too smart about
>>>> encouraging the use of a known extension. Try it and let me know...
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Mirko
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: Overriding the default resource factory for .ecore files [message #428664 is a reply to message #428656] |
Thu, 26 March 2009 08:58 |
Mirko Seifert
Messages: 31
Registered: July 2009 |
Member |
|
|
Hi Ed,
thanks for explaining the implications. I'm convinced now that added the
extension point is the better choice.
I'll set up a workspace with the current head revision of EMF and try to
come up with an initial patch. Shall we track this in bugzilla rather
than the newsgroup?
Cheers,
Mirko
Ed Merks schrieb:
> Mirko,
>
> Comments below.
>
> Mirko Seifert wrote:
>> Hi Ed,
>>
>> I think adding such an extension point could certainly solve the
>> problem at hand. I currently build against EMF 2.4.2, but could use
>> 2.5 as well. I'm also willing to verify and support the design of the
>> feature.
>>
>> However, before we start to do so I'd like to go back one step and
>> bring up the discussion about the extension parsers and the content
>> parsers again. I'm sorry, because you might be tired of that
>> discussion, but I just want to understand this more deeply:
>>
>> I'm aware that you do not want to change the priorities to make sure
>> existing clients still get the behavior they expect. I agree with that.
>>
>> But, for a second let's suppose the EcoreResourceFactoryImpl would not
>> be registered as extension parser, but as content parser. What are the
>> implications?
> The file has to be opened and analyzed to be sure that it's really XML
> content with a root element from the Ecore namespace; and expense not
> incurred in the past.
>>
>> I think functionally it would be the same, because all Ecore files
>> saved as XMI could still be loaded.
> People care about more than function, they also care about performance.
>> Non-functionally (in terms of performance) there would obviously be a
>> difference, because the content parser needs to have a look into every
>> '.ecore' file to decide whether it is an XMI file or not.
> Indeed.
>> However, this happens only when files change and it requires looking
>> at the first (four?) bytes in the file only (to check whether the XMI
>> header is there).
> No, it has to look at the namespace of the root element. Outside of the
> workspace, this information isn't cached and certainly isn't free to
> compute.
>> The question is, whether this is really significant for a reasonable
>> number of .ecore files in a workspace. Am I missing something here?
> It's indeed a question and I'll assure you that it's significant
> compared to syntactically matching an extension on a URI. IO verses a
> simple syntactic check...
>>
>> Since EMF provides this powerful content parsing extension point that
>> allows to save different content types in files with the same
>> extension then why should we not make use of it for ecore itself.
> From a content type point fo view, one could imagine specifying Ecore
> content, but the hiearchy for text content verses XML content would be
> parallel and content type hierarchies don't support multiple inheritance...
>>
>> Again, sorry for bringing this up again, but I want to make sure that
>> we are not adding something here that solves only the (small) problem
>> with the generator model wizard, but is actually about something else.
>> Other tools might also ask for .ecore files and face the same problem.
> Content types are all fine and cool, but I'm always taken aback by how
> poorly the overall concepts are considered. Imagine 1000 parsers all
> looking at the same *.xml file to decide if it's content they
> recognized. Each one duplicates an full XML parse of the start of the
> file. Does that really scale well? I imagine not.
>>
>> Cheers,
>>
>> Mirko
>>
>>
>> Ed Merks wrote:
>>> Mirko,
>>>
>>> We probably should be more forgiving but I suppose if we wanted to
>>> get fancy, we'd have an extension point that would allow one to
>>> specify additional extensions for resource types that will
>>> transparently be treated as containing Ecore models during import.
>>> I'd certainly be willing to entertain that, but I'll need help with
>>> verifying that the design works for you, and I'm not at my most
>>> productive best these days for personal reasons. Are you developing
>>> against 2.5. Will this help?
>>>
>>>
>>> Mirko Seifert wrote:
>>>> Hi Ed,
>>>>
>>>> as it seems that my problem boils down to getting the EMF generator
>>>> model wizard accept files other than '.ecore' I'll shorten the
>>>> previous discussion a little.
>>>>
>>>> I followed your suggestion, used a different extension (.tecore) and
>>>> directly entered a URI to my textual Ecore model
>>>> (/projectname/new.tecore), which is then indeed loaded by the
>>>> wizard. However, after clicking "Next" the wizard correctly shows
>>>> the packages defined in new.tecore, but complains "The Ecore model
>>>> file name for package 'someEPackageName' must end in '.ecore' or
>>>> '.emof'". So I can't continue.
>>>>
>>>> Maybe there is a way to tell the wizard to accept other extensions?
>>>>
>>>> Cheers,
>>>>
>>>> Mirko
>>>>
>>>>
>>>> Ed Merks schrieb:
>>>>> Mirko,
>>>>>
>>>>> comments below.
>>>>>
>>>>> Mirko Seifert wrote:
>>>>>> Hi Ed,
>>>>>>
>>>>>> Ed Merks wrote:
>>>>>>> Mirko,
>>>>>>>
>>>>>>> Comments below.
>>>>>>>
>>>>>>> Mirko Seifert wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I want to register a resource factory for .ecore files that
>>>>>>>> loads Ecore files represented in a text syntax rather than XMI.
>>>>>>> Reusing the same extension seems like a bad idea...
>>>>>> I know, but using a different extension (e.g. 'tecore') does not
>>>>>> work because I can't create generator models for such files.
>>>>> I know the file dialog makes it hard and the workspace dialog only
>>>>> shows matching extension, but I'm pretty sure you could enter a URI
>>>>> with any extension...
>>>>>> As generating code is the most usual task that is performed on the
>>>>>> ecore models, this is desperately needed.
>>>>> It's worth trying to enter URIs with different extension manually
>>>>> and see how much of all this will "just works". Maybe all of it.
>>>>>>> Now all content type registrations will be considered first in
>>>>>>> this resource set. I think reusing the same extension for a
>>>>>>> different format is probably a bad idea though....
>>>>>>
>>>>>> Do you have any other idea/comment?
>>>>> I think it's mostly a problem that the dialogs are too smart about
>>>>> encouraging the use of a known extension. Try it and let me know...
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Mirko
|
|
| |
| Re: Overriding the default resource factory for .ecore files [message #428666 is a reply to message #428665] |
Thu, 26 March 2009 10:13 |
Andy Carpenter
Messages: 145
Registered: July 2009 |
Senior Member |
|
|
> thanks for the information. We ran into the same problems and solved them
> in similar way.
>
> I was wondering why you need an additional meta model (the EmfaticMM). We
> do directly create an instance of the EcoreMM. Could you explain that a
> little?
On the assumption that it would minimise development effort, we used
existing tools for the m2m (ATL), and t2m and m2t (both TCS)
transformations.
For TCS we found there were a few places in the Emfatic syntax were
we did not want to directly use the EcoreMM. These mainly occurred were
a collection of items are allowed. For example, the declarations within a
package. These can be subpackages, or classifiers and the EcoreMM
has separate attributes for both. With TCS, syntactically the values for two
attributes must be separated, so all subpackages would have to occur
before all classifiers (or visa versa). To allow them to be intermixed, we
needed a single attribute; hence, a different MM. We also had a change
for modifiers so that they could be used in any order. The differences
between the EmfaticMM and the EcoreMM are very slight and the m2m
transformations are almost 1:1. Had we been able to use the EcoreMM,
we would not have needed the m2m transformations.
Andy.
|
|
|
| Re: Overriding the default resource factory for .ecore files [message #428667 is a reply to message #428664] |
Thu, 26 March 2009 11:29 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Mirko,
Bugzilla is the best place to share patches.
Mirko Seifert wrote:
> Hi Ed,
>
> thanks for explaining the implications. I'm convinced now that added
> the extension point is the better choice.
>
> I'll set up a workspace with the current head revision of EMF and try
> to come up with an initial patch. Shall we track this in bugzilla
> rather than the newsgroup?
>
> Cheers,
>
> Mirko
>
>
> Ed Merks schrieb:
>> Mirko,
>>
>> Comments below.
>>
>> Mirko Seifert wrote:
>>> Hi Ed,
>>>
>>> I think adding such an extension point could certainly solve the
>>> problem at hand. I currently build against EMF 2.4.2, but could use
>>> 2.5 as well. I'm also willing to verify and support the design of
>>> the feature.
>>>
>>> However, before we start to do so I'd like to go back one step and
>>> bring up the discussion about the extension parsers and the content
>>> parsers again. I'm sorry, because you might be tired of that
>>> discussion, but I just want to understand this more deeply:
>>>
>>> I'm aware that you do not want to change the priorities to make sure
>>> existing clients still get the behavior they expect. I agree with that.
>>>
>>> But, for a second let's suppose the EcoreResourceFactoryImpl would
>>> not be registered as extension parser, but as content parser. What
>>> are the implications?
>> The file has to be opened and analyzed to be sure that it's really
>> XML content with a root element from the Ecore namespace; and expense
>> not incurred in the past.
>>>
>>> I think functionally it would be the same, because all Ecore files
>>> saved as XMI could still be loaded.
>> People care about more than function, they also care about performance.
>>> Non-functionally (in terms of performance) there would obviously be
>>> a difference, because the content parser needs to have a look into
>>> every '.ecore' file to decide whether it is an XMI file or not.
>> Indeed.
>>> However, this happens only when files change and it requires looking
>>> at the first (four?) bytes in the file only (to check whether the
>>> XMI header is there).
>> No, it has to look at the namespace of the root element. Outside of
>> the workspace, this information isn't cached and certainly isn't free
>> to compute.
>>> The question is, whether this is really significant for a reasonable
>>> number of .ecore files in a workspace. Am I missing something here?
>> It's indeed a question and I'll assure you that it's significant
>> compared to syntactically matching an extension on a URI. IO verses
>> a simple syntactic check...
>>>
>>> Since EMF provides this powerful content parsing extension point
>>> that allows to save different content types in files with the same
>>> extension then why should we not make use of it for ecore itself.
>> From a content type point fo view, one could imagine specifying
>> Ecore content, but the hiearchy for text content verses XML content
>> would be parallel and content type hierarchies don't support multiple
>> inheritance...
>>>
>>> Again, sorry for bringing this up again, but I want to make sure
>>> that we are not adding something here that solves only the (small)
>>> problem with the generator model wizard, but is actually about
>>> something else. Other tools might also ask for .ecore files and face
>>> the same problem.
>> Content types are all fine and cool, but I'm always taken aback by
>> how poorly the overall concepts are considered. Imagine 1000 parsers
>> all looking at the same *.xml file to decide if it's content they
>> recognized. Each one duplicates an full XML parse of the start of
>> the file. Does that really scale well? I imagine not.
>>>
>>> Cheers,
>>>
>>> Mirko
>>>
>>>
>>> Ed Merks wrote:
>>>> Mirko,
>>>>
>>>> We probably should be more forgiving but I suppose if we wanted to
>>>> get fancy, we'd have an extension point that would allow one to
>>>> specify additional extensions for resource types that will
>>>> transparently be treated as containing Ecore models during
>>>> import. I'd certainly be willing to entertain that, but I'll need
>>>> help with verifying that the design works for you, and I'm not at
>>>> my most productive best these days for personal reasons. Are you
>>>> developing against 2.5. Will this help?
>>>>
>>>>
>>>> Mirko Seifert wrote:
>>>>> Hi Ed,
>>>>>
>>>>> as it seems that my problem boils down to getting the EMF
>>>>> generator model wizard accept files other than '.ecore' I'll
>>>>> shorten the previous discussion a little.
>>>>>
>>>>> I followed your suggestion, used a different extension (.tecore)
>>>>> and directly entered a URI to my textual Ecore model
>>>>> (/projectname/new.tecore), which is then indeed loaded by the
>>>>> wizard. However, after clicking "Next" the wizard correctly shows
>>>>> the packages defined in new.tecore, but complains "The Ecore model
>>>>> file name for package 'someEPackageName' must end in '.ecore' or
>>>>> '.emof'". So I can't continue.
>>>>>
>>>>> Maybe there is a way to tell the wizard to accept other extensions?
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Mirko
>>>>>
>>>>>
>>>>> Ed Merks schrieb:
>>>>>> Mirko,
>>>>>>
>>>>>> comments below.
>>>>>>
>>>>>> Mirko Seifert wrote:
>>>>>>> Hi Ed,
>>>>>>>
>>>>>>> Ed Merks wrote:
>>>>>>>> Mirko,
>>>>>>>>
>>>>>>>> Comments below.
>>>>>>>>
>>>>>>>> Mirko Seifert wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I want to register a resource factory for .ecore files that
>>>>>>>>> loads Ecore files represented in a text syntax rather than XMI.
>>>>>>>> Reusing the same extension seems like a bad idea...
>>>>>>> I know, but using a different extension (e.g. 'tecore') does not
>>>>>>> work because I can't create generator models for such files.
>>>>>> I know the file dialog makes it hard and the workspace dialog
>>>>>> only shows matching extension, but I'm pretty sure you could
>>>>>> enter a URI with any extension...
>>>>>>> As generating code is the most usual task that is performed on
>>>>>>> the ecore models, this is desperately needed.
>>>>>> It's worth trying to enter URIs with different extension manually
>>>>>> and see how much of all this will "just works". Maybe all of it.
>>>>>>>> Now all content type registrations will be considered first in
>>>>>>>> this resource set. I think reusing the same extension for a
>>>>>>>> different format is probably a bad idea though....
>>>>>>>
>>>>>>> Do you have any other idea/comment?
>>>>>> I think it's mostly a problem that the dialogs are too smart
>>>>>> about encouraging the use of a known extension. Try it and let
>>>>>> me know...
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Mirko
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Tue Apr 16 09:50:21 GMT 2024
Powered by FUDForum. Page generated in 0.19873 seconds |
] 
Search
Help
Register
Login
Home
