Home » Modeling » EMF » Retrieve namespace URI
| | | |
| Re: Retrieve namespace URI [message #420144 is a reply to message #420143] |
Thu, 19 June 2008 09:08   |
 J. Rietz
Messages: 40
Registered: July 2009 |
Member |
|
|
Hi,
See comments below.
/Joachim
Matthias Schoettle wrote:
> Hi Joachim,
>> Yes, I know about the "eNS_URI" field, but I can't use that one since
>> the nsURI I want to retrieve is the one for the "old" model resource.
>> The "eNS_URI" field is for the "new" model...
> So you don't have the generated model for the old model anymore?
> Can't you load the old model ecore file and retrieve the namespace URI
> there?!
No, not in runtime. Only the new one and ecore2xml mapping file.
However, I found the XMLHelper class, might be something to use for
resource parsing... Anyone who have tried it? Is this a good way to
proceed?
This one is instanciated by new XMIHelperImpl(xmlResource) and contains a
getNamespaceURI() method...
>> BTW: About the ecore2ecore I've used the wiki recipe;
>> http://wiki.eclipse.org/EMF/Recipes#Recipe:_Data_Migration
>> and that worked well for me.
>> I have a command to trigger the transformation. What the command does is
>> to first load the "old" resource with extended meta data;
>> xmlResource.load(extendedMetaDataMap), and then save it;
>> xmlResource.save(null).
>> One important thing I noticed was to NOT use the same extended meta data
>> for the save. Passing the same extended meta data at save results in a
>> re-transformation of model meaning that you get the "old" model again ;o
> I tried out the recipe but I always got the old model ;-)
> But this might be because I am trying to export one model into the other.
> Do you use no extended meta data when saving or just (an)other extended
> meta data?
I use extended meta data at load but no extended meta data at save, just
null argument to save().
> Matthias
|
|
| |
| Re: Retrieve namespace URI [message #420155 is a reply to message #420144] |
Thu, 19 June 2008 12:59 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Joachim,
In the end, you really do need to read the resource, so why not just
read it off to the side to get the information? Maybe it will help if I
understand why you need this because perhaps there's a better way.
Joachim Rietz wrote:
> Hi,
> See comments below.
>
> /Joachim
>
> Matthias Schoettle wrote:
>
>> Hi Joachim,
>
>>> Yes, I know about the "eNS_URI" field, but I can't use that one
>>> since the nsURI I want to retrieve is the one for the "old" model
>>> resource. The "eNS_URI" field is for the "new" model...
>
>> So you don't have the generated model for the old model anymore?
>> Can't you load the old model ecore file and retrieve the namespace
>> URI there?!
> No, not in runtime. Only the new one and ecore2xml mapping file.
> However, I found the XMLHelper class, might be something to use for
> resource parsing... Anyone who have tried it? Is this a good way to
> proceed?
> This one is instanciated by new XMIHelperImpl(xmlResource) and
> contains a getNamespaceURI() method...
>
>>> BTW: About the ecore2ecore I've used the wiki recipe;
>>> http://wiki.eclipse.org/EMF/Recipes#Recipe:_Data_Migration
>>> and that worked well for me.
>>> I have a command to trigger the transformation. What the command
>>> does is to first load the "old" resource with extended meta data;
>>> xmlResource.load(extendedMetaDataMap), and then save it;
>>> xmlResource.save(null).
>>> One important thing I noticed was to NOT use the same extended meta
>>> data for the save. Passing the same extended meta data at save
>>> results in a re-transformation of model meaning that you get the
>>> "old" model again ;o
>
>> I tried out the recipe but I always got the old model ;-)
>> But this might be because I am trying to export one model into the
>> other.
>
>> Do you use no extended meta data when saving or just (an)other
>> extended meta data?
> I use extended meta data at load but no extended meta data at save,
> just null argument to save().
>
>> Matthias
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Retrieve namespace URI [message #420215 is a reply to message #420155] |
Mon, 23 June 2008 05:49 |
J. Rietz
Messages: 40
Registered: July 2009 |
Member |
|
|
Ed,
I'll try to explain briefly my needs.
I'm using ecore2ecore transformation and I want to deliver support for
multiple such transformations in the runtime app. I.e. transformation
support from multiple "old" model versions into latest (the model version
is placed within the nsURI).
I have the code working for this multiple transformation support, but the
issue remains to really know when having an "old" model version if it is
supported to be transformed by one of the delivered transformations.
For this issue I need to know its nsURI to be able to compare against the
list of nsURI's I support transformations for. I really just need to know
the nsURI string of the "old" resource...which obviously wasn't that easy
I've hoped for...
I don't see that reading it off to the side to get the information is a
solution, since that means that I have to ship the whole bunch of emf
model code for the old models as well, or...
As a desperate solution I just tested to use the XMLHelper, having no idea
if this is recommendable or not or how it is supposed to be used...
However, it looked like the only parameters it needed was the resource
itself and the corresponding EPackage.
Could this be a way?
XMLResource xmlResource = (XMLResource)
resourceSet.createResource(oldResourceURI);
if (xmlResource != null) {
XMLHelper xmlHelper = new XMIHelperImpl(xmlResource);
String packagePrefix = xmlHelper.getPrefix(oldEPackage);
return xmlHelper.getNamespaceURI(packagePrefix);
}
Really need some advice, I'm stuck :P
/Joachim
Ed Merks wrote:
> Joachim,
> In the end, you really do need to read the resource, so why not just
> read it off to the side to get the information? Maybe it will help if I
> understand why you need this because perhaps there's a better way.
> Joachim Rietz wrote:
>> Hi,
>> See comments below.
>>
>> /Joachim
>>
>> Matthias Schoettle wrote:
>>
>>> Hi Joachim,
>>
>>>> Yes, I know about the "eNS_URI" field, but I can't use that one
>>>> since the nsURI I want to retrieve is the one for the "old" model
>>>> resource. The "eNS_URI" field is for the "new" model...
>>
>>> So you don't have the generated model for the old model anymore?
>>> Can't you load the old model ecore file and retrieve the namespace
>>> URI there?!
>> No, not in runtime. Only the new one and ecore2xml mapping file.
>> However, I found the XMLHelper class, might be something to use for
>> resource parsing... Anyone who have tried it? Is this a good way to
>> proceed?
>> This one is instanciated by new XMIHelperImpl(xmlResource) and
>> contains a getNamespaceURI() method...
>>
>>>> BTW: About the ecore2ecore I've used the wiki recipe;
>>>> http://wiki.eclipse.org/EMF/Recipes#Recipe:_Data_Migration
>>>> and that worked well for me.
>>>> I have a command to trigger the transformation. What the command
>>>> does is to first load the "old" resource with extended meta data;
>>>> xmlResource.load(extendedMetaDataMap), and then save it;
>>>> xmlResource.save(null).
>>>> One important thing I noticed was to NOT use the same extended meta
>>>> data for the save. Passing the same extended meta data at save
>>>> results in a re-transformation of model meaning that you get the
>>>> "old" model again ;o
>>
>>> I tried out the recipe but I always got the old model ;-)
>>> But this might be because I am trying to export one model into the
>>> other.
>>
>>> Do you use no extended meta data when saving or just (an)other
>>> extended meta data?
>> I use extended meta data at load but no extended meta data at save,
>> just null argument to save().
>>
>>> Matthias
>>
>>
|
|
|
| Re: Retrieve namespace URI [message #420216 is a reply to message #420215] |
Mon, 23 June 2008 06:05 |
J. Rietz
Messages: 40
Registered: July 2009 |
Member |
|
|
Just found out that my way of using XMLHelper doesn't seem to be possible,
since to know which "old" EPackage to use I obviously need to know the
nsURI and that's what I'm trying to get...
So, I'm really stuck here ;P
Joachim Rietz wrote:
> Ed,
> I'll try to explain briefly my needs.
> I'm using ecore2ecore transformation and I want to deliver support for
> multiple such transformations in the runtime app. I.e. transformation
> support from multiple "old" model versions into latest (the model version
> is placed within the nsURI).
> I have the code working for this multiple transformation support, but the
> issue remains to really know when having an "old" model version if it is
> supported to be transformed by one of the delivered transformations.
> For this issue I need to know its nsURI to be able to compare against the
> list of nsURI's I support transformations for. I really just need to know
> the nsURI string of the "old" resource...which obviously wasn't that easy
> I've hoped for...
> I don't see that reading it off to the side to get the information is a
> solution, since that means that I have to ship the whole bunch of emf
> model code for the old models as well, or...
> As a desperate solution I just tested to use the XMLHelper, having no idea
> if this is recommendable or not or how it is supposed to be used...
> However, it looked like the only parameters it needed was the resource
> itself and the corresponding EPackage.
> Could this be a way?
> XMLResource xmlResource = (XMLResource)
> resourceSet.createResource(oldResourceURI);
> if (xmlResource != null) {
> XMLHelper xmlHelper = new XMIHelperImpl(xmlResource);
> String packagePrefix = xmlHelper.getPrefix(oldEPackage);
> return xmlHelper.getNamespaceURI(packagePrefix);
> }
> Really need some advice, I'm stuck :P
> /Joachim
> Ed Merks wrote:
>> Joachim,
>> In the end, you really do need to read the resource, so why not just
>> read it off to the side to get the information? Maybe it will help if I
>> understand why you need this because perhaps there's a better way.
>> Joachim Rietz wrote:
>>> Hi,
>>> See comments below.
>>>
>>> /Joachim
>>>
>>> Matthias Schoettle wrote:
>>>
>>>> Hi Joachim,
>>>
>>>>> Yes, I know about the "eNS_URI" field, but I can't use that one
>>>>> since the nsURI I want to retrieve is the one for the "old" model
>>>>> resource. The "eNS_URI" field is for the "new" model...
>>>
>>>> So you don't have the generated model for the old model anymore?
>>>> Can't you load the old model ecore file and retrieve the namespace
>>>> URI there?!
>>> No, not in runtime. Only the new one and ecore2xml mapping file.
>>> However, I found the XMLHelper class, might be something to use for
>>> resource parsing... Anyone who have tried it? Is this a good way to
>>> proceed?
>>> This one is instanciated by new XMIHelperImpl(xmlResource) and
>>> contains a getNamespaceURI() method...
>>>
>>>>> BTW: About the ecore2ecore I've used the wiki recipe;
>>>>> http://wiki.eclipse.org/EMF/Recipes#Recipe:_Data_Migration
>>>>> and that worked well for me.
>>>>> I have a command to trigger the transformation. What the command
>>>>> does is to first load the "old" resource with extended meta data;
>>>>> xmlResource.load(extendedMetaDataMap), and then save it;
>>>>> xmlResource.save(null).
>>>>> One important thing I noticed was to NOT use the same extended meta
>>>>> data for the save. Passing the same extended meta data at save
>>>>> results in a re-transformation of model meaning that you get the
>>>>> "old" model again ;o
>>>
>>>> I tried out the recipe but I always got the old model ;-)
>>>> But this might be because I am trying to export one model into the
>>>> other.
>>>
>>>> Do you use no extended meta data when saving or just (an)other
>>>> extended meta data?
>>> I use extended meta data at load but no extended meta data at save,
>>> just null argument to save().
>>>
>>>> Matthias
>>>
>>>
|
|
|
| Re: Retrieve namespace URI [message #420219 is a reply to message #420215] |
Mon, 23 June 2008 12:03 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------080804000101060000090008
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Jochim,
Comments below.
Joachim Rietz wrote:
> Ed,
>
> I'll try to explain briefly my needs.
> I'm using ecore2ecore transformation and I want to deliver support for
> multiple such transformations in the runtime app. I.e. transformation
> support from multiple "old" model versions into latest (the model
> version is placed within the nsURI).
> I have the code working for this multiple transformation support, but
> the issue remains to really know when having an "old" model version if
> it is supported to be transformed by one of the delivered transformations.
EMF 2.4 supports content types. The way that's implemented, the
namespace of the root element is determined by parsing just the first
element (or elements in the case of XMI) to find that namespace. A
resource factory can then be registered specific to that content type
and hence specific to the namespace in the document. So I imagine you
could use that to give each version a different content type.
> For this issue I need to know its nsURI to be able to compare against
> the list of nsURI's I support transformations for. I really just need
> to know the nsURI string of the "old" resource...which obviously
> wasn't that easy I've hoped for...
You could look in XMLContentHandlerImpl/RootXMLContentHandlerImpl to see
how we implement content type support.
> I don't see that reading it off to the side to get the information is
> a solution, since that means that I have to ship the whole bunch of
> emf model code for the old models as well, or...
It just wasn't clear if you were reading old Ecore models or old
instances of the resource. It sounds like the latter but previously I'd
assumed the former.
>
> As a desperate solution I just tested to use the XMLHelper, having no
> idea if this is recommendable or not or how it is supposed to be used...
> However, it looked like the only parameters it needed was the resource
> itself and the corresponding EPackage.
> Could this be a way?
>
> XMLResource xmlResource = (XMLResource)
> resourceSet.createResource(oldResourceURI);
> if (xmlResource != null) {
> XMLHelper xmlHelper = new XMIHelperImpl(xmlResource);
> String packagePrefix = xmlHelper.getPrefix(oldEPackage);
> return xmlHelper.getNamespaceURI(packagePrefix);
> }
>
>
> Really need some advice, I'm stuck :P
It sounds like content types are the perfect fit... Here's an example:
<extension
point="org.eclipse.core.runtime.contentTypes">
<content-type
base-type="org.eclipse.emf.ecore.xmi"
file-extensions="ecore"
*id="org.eclipse.emf.ecore"*
name="%_UI_Ecore_content_type"
priority="normal">
<describer
class=" org.eclipse.emf.ecore.xmi.impl.RootXMLContentHandlerImpl$Des criber ">
<parameter
name="namespace"
value="http://www.eclipse.org/emf/2002/Ecore">
</parameter>
<parameter
name="kind"
value="xmi">
</parameter>
</describer>
</content-type>
</extension>
<extension
point="org.eclipse.emf.ecore.content_parser">
<parser
class="org.eclipse.emf.ecore.xmi.impl.EcoreResourceFactoryImpl "
*contentTypeIdentifier="org.eclipse.emf.ecore"*>
</parser>
</extension>
>
> /Joachim
>
> Ed Merks wrote:
>
>> Joachim,
>
>> In the end, you really do need to read the resource, so why not just
>> read it off to the side to get the information? Maybe it will help
>> if I understand why you need this because perhaps there's a better way.
>
>
>> Joachim Rietz wrote:
>>> Hi,
>>> See comments below.
>>>
>>> /Joachim
>>>
>>> Matthias Schoettle wrote:
>>>
>>>> Hi Joachim,
>>>
>>>>> Yes, I know about the "eNS_URI" field, but I can't use that one
>>>>> since the nsURI I want to retrieve is the one for the "old" model
>>>>> resource. The "eNS_URI" field is for the "new" model...
>>>
>>>> So you don't have the generated model for the old model anymore?
>>>> Can't you load the old model ecore file and retrieve the namespace
>>>> URI there?!
>>> No, not in runtime. Only the new one and ecore2xml mapping file.
>>> However, I found the XMLHelper class, might be something to use for
>>> resource parsing... Anyone who have tried it? Is this a good way to
>>> proceed?
>>> This one is instanciated by new XMIHelperImpl(xmlResource) and
>>> contains a getNamespaceURI() method...
>>>
>>>>> BTW: About the ecore2ecore I've used the wiki recipe;
>>>>> http://wiki.eclipse.org/EMF/Recipes#Recipe:_Data_Migration
>>>>> and that worked well for me.
>>>>> I have a command to trigger the transformation. What the command
>>>>> does is to first load the "old" resource with extended meta data;
>>>>> xmlResource.load(extendedMetaDataMap), and then save it;
>>>>> xmlResource.save(null).
>>>>> One important thing I noticed was to NOT use the same extended
>>>>> meta data for the save. Passing the same extended meta data at
>>>>> save results in a re-transformation of model meaning that you get
>>>>> the "old" model again ;o
>>>
>>>> I tried out the recipe but I always got the old model ;-)
>>>> But this might be because I am trying to export one model into the
>>>> other.
>>>
>>>> Do you use no extended meta data when saving or just (an)other
>>>> extended meta data?
>>> I use extended meta data at load but no extended meta data at save,
>>> just null argument to save().
>>>
>>>> Matthias
>>>
>>>
>
>
--------------080804000101060000090008
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Jochim,<br>
<br>
Comments below.<br>
<br>
Joachim Rietz wrote:
<blockquote
cite="mid:9f4c413a98eff6e75eb94cefddaff010$1@www.eclipse.org"
type="cite">Ed,
<br>
<br>
I'll try to explain briefly my needs.
<br>
I'm using ecore2ecore transformation and I want to deliver support for
multiple such transformations in the runtime app. I.e. transformation
support from multiple "old" model versions into latest (the model
version is placed within the nsURI).
<br>
I have the code working for this multiple transformation support, but
the issue remains to really know when having an "old" model version if
it is supported to be transformed by one of the delivered
transformations.</blockquote>
EMF 2.4 supports content types.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Retrieve namespace URI [message #420242 is a reply to message #420219] |
Tue, 24 June 2008 08:35 |
J. Rietz
Messages: 40
Registered: July 2009 |
Member |
|
|
Hi,
Thanks for comments Ed, they gave me further knowledge about content types
;)
Unforunately, I don't see that the solution to register a content type
solves my needs, I still need to get the namespace string from an old
instance resource.
I've had a look in XMLContentHandlerImpl/RootXMLContentHandlerImpl but
don't really understand how it fits in the context.
Is it possible to use XMLContentHandlerImpl/RootXMLContentHandlerImpl in
some way to just get hold of the namespace string?
What I have is a resource from which I just want to parse out the
namespace uri.
Really appreciate if someone could share an example for this kind of task
if possible.
Regards,
Joachim
Ed Merks wrote:
> Jochim,
> Comments below.
> Joachim Rietz wrote:
>> Ed,
>>
>> I'll try to explain briefly my needs.
>> I'm using ecore2ecore transformation and I want to deliver support for
>> multiple such transformations in the runtime app. I.e. transformation
>> support from multiple "old" model versions into latest (the model
>> version is placed within the nsURI).
>> I have the code working for this multiple transformation support, but
>> the issue remains to really know when having an "old" model version if
>> it is supported to be transformed by one of the delivered transformations.
> EMF 2.4 supports content types. The way that's implemented, the
> namespace of the root element is determined by parsing just the first
> element (or elements in the case of XMI) to find that namespace. A
> resource factory can then be registered specific to that content type
> and hence specific to the namespace in the document. So I imagine you
> could use that to give each version a different content type.
>> For this issue I need to know its nsURI to be able to compare against
>> the list of nsURI's I support transformations for. I really just need
>> to know the nsURI string of the "old" resource...which obviously
>> wasn't that easy I've hoped for...
> You could look in XMLContentHandlerImpl/RootXMLContentHandlerImpl to see
> how we implement content type support.
>> I don't see that reading it off to the side to get the information is
>> a solution, since that means that I have to ship the whole bunch of
>> emf model code for the old models as well, or...
> It just wasn't clear if you were reading old Ecore models or old
> instances of the resource. It sounds like the latter but previously I'd
> assumed the former.
>>
>> As a desperate solution I just tested to use the XMLHelper, having no
>> idea if this is recommendable or not or how it is supposed to be used...
>> However, it looked like the only parameters it needed was the resource
>> itself and the corresponding EPackage.
>> Could this be a way?
>>
>> XMLResource xmlResource = (XMLResource)
>> resourceSet.createResource(oldResourceURI);
>> if (xmlResource != null) {
>> XMLHelper xmlHelper = new XMIHelperImpl(xmlResource);
>> String packagePrefix = xmlHelper.getPrefix(oldEPackage);
>> return xmlHelper.getNamespaceURI(packagePrefix);
>> }
>>
>>
>> Really need some advice, I'm stuck :P
> It sounds like content types are the perfect fit... Here's an example:
> <extension
> point="org.eclipse.core.runtime.contentTypes">
> <content-type
> base-type="org.eclipse.emf.ecore.xmi"
> file-extensions="ecore"
> *id="org.eclipse.emf.ecore"*
> name="%_UI_Ecore_content_type"
> priority="normal">
> <describer
>
class=" org.eclipse.emf.ecore.xmi.impl.RootXMLContentHandlerImpl$Des criber ">
> <parameter
> name="namespace"
> value="http://www.eclipse.org/emf/2002/Ecore">
> </parameter>
> <parameter
> name="kind"
> value="xmi">
> </parameter>
> </describer>
> </content-type>
> </extension>
> <extension
> point="org.eclipse.emf.ecore.content_parser">
> <parser
> class="org.eclipse.emf.ecore.xmi.impl.EcoreResourceFactoryImpl "
> *contentTypeIdentifier="org.eclipse.emf.ecore"*>
> </parser>
> </extension>
>>
>> /Joachim
>>
>> Ed Merks wrote:
>>
>>> Joachim,
>>
>>> In the end, you really do need to read the resource, so why not just
>>> read it off to the side to get the information? Maybe it will help
>>> if I understand why you need this because perhaps there's a better way.
>>
>>
>>> Joachim Rietz wrote:
>>>> Hi,
>>>> See comments below.
>>>>
>>>> /Joachim
>>>>
>>>> Matthias Schoettle wrote:
>>>>
>>>>> Hi Joachim,
>>>>
>>>>>> Yes, I know about the "eNS_URI" field, but I can't use that one
>>>>>> since the nsURI I want to retrieve is the one for the "old" model
>>>>>> resource. The "eNS_URI" field is for the "new" model...
>>>>
>>>>> So you don't have the generated model for the old model anymore?
>>>>> Can't you load the old model ecore file and retrieve the namespace
>>>>> URI there?!
>>>> No, not in runtime. Only the new one and ecore2xml mapping file.
>>>> However, I found the XMLHelper class, might be something to use for
>>>> resource parsing... Anyone who have tried it? Is this a good way to
>>>> proceed?
>>>> This one is instanciated by new XMIHelperImpl(xmlResource) and
>>>> contains a getNamespaceURI() method...
>>>>
>>>>>> BTW: About the ecore2ecore I've used the wiki recipe;
>>>>>> http://wiki.eclipse.org/EMF/Recipes#Recipe:_Data_Migration
>>>>>> and that worked well for me.
>>>>>> I have a command to trigger the transformation. What the command
>>>>>> does is to first load the "old" resource with extended meta data;
>>>>>> xmlResource.load(extendedMetaDataMap), and then save it;
>>>>>> xmlResource.save(null).
>>>>>> One important thing I noticed was to NOT use the same extended
>>>>>> meta data for the save. Passing the same extended meta data at
>>>>>> save results in a re-transformation of model meaning that you get
>>>>>> the "old" model again ;o
>>>>
>>>>> I tried out the recipe but I always got the old model ;-)
>>>>> But this might be because I am trying to export one model into the
>>>>> other.
>>>>
>>>>> Do you use no extended meta data when saving or just (an)other
>>>>> extended meta data?
>>>> I use extended meta data at load but no extended meta data at save,
>>>> just null argument to save().
>>>>
>>>>> Matthias
>>>>
>>>>
>>
>>
|
|
|
| Re: Retrieve namespace URI [message #420248 is a reply to message #420242] |
Tue, 24 June 2008 13:52 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Joachim,
Comments below.
Joachim Rietz wrote:
> Hi,
>
> Thanks for comments Ed, they gave me further knowledge about content
> types ;)
> Unforunately, I don't see that the solution to register a content type
> solves my needs, I still need to get the namespace string from an old
> instance resource.
Well, the content type registration is based on the namespace, so you
old resource type could have a specific content type associated with it...
>
> I've had a look in XMLContentHandlerImpl/RootXMLContentHandlerImpl but
> don't really understand how it fits in the context.
> Is it possible to use XMLContentHandlerImpl/RootXMLContentHandlerImpl
> in some way to just get hold of the namespace string?
XMLContentHandlerImpl.createResource does pretty much exactly what
you're asking. So you could use that directly, use it as an example, or
exploit the fact that each old nsURI could define a different content
type and that this would allow you to register a resource factory for
creating resources specific to that old nsURI...
> What I have is a resource from which I just want to parse out the
> namespace uri.
> Really appreciate if someone could share an example for this kind of
> task if possible.
>
> Regards,
> Joachim
>
> Ed Merks wrote:
>
>> Jochim,
>
>> Comments below.
>
>> Joachim Rietz wrote:
>>> Ed,
>>>
>>> I'll try to explain briefly my needs.
>>> I'm using ecore2ecore transformation and I want to deliver support
>>> for multiple such transformations in the runtime app. I.e.
>>> transformation support from multiple "old" model versions into
>>> latest (the model version is placed within the nsURI).
>>> I have the code working for this multiple transformation support,
>>> but the issue remains to really know when having an "old" model
>>> version if it is supported to be transformed by one of the delivered
>>> transformations.
>> EMF 2.4 supports content types. The way that's implemented, the
>> namespace of the root element is determined by parsing just the first
>> element (or elements in the case of XMI) to find that namespace. A
>> resource factory can then be registered specific to that content type
>> and hence specific to the namespace in the document. So I imagine
>> you could use that to give each version a different content type.
>>> For this issue I need to know its nsURI to be able to compare
>>> against the list of nsURI's I support transformations for. I really
>>> just need to know the nsURI string of the "old" resource...which
>>> obviously wasn't that easy I've hoped for...
>> You could look in XMLContentHandlerImpl/RootXMLContentHandlerImpl to
>> see how we implement content type support.
>>> I don't see that reading it off to the side to get the information
>>> is a solution, since that means that I have to ship the whole bunch
>>> of emf model code for the old models as well, or...
>> It just wasn't clear if you were reading old Ecore models or old
>> instances of the resource. It sounds like the latter but previously
>> I'd assumed the former.
>>>
>>> As a desperate solution I just tested to use the XMLHelper, having
>>> no idea if this is recommendable or not or how it is supposed to be
>>> used...
>>> However, it looked like the only parameters it needed was the
>>> resource itself and the corresponding EPackage.
>>> Could this be a way?
>>>
>>> XMLResource xmlResource = (XMLResource)
>>> resourceSet.createResource(oldResourceURI);
>>> if (xmlResource != null) {
>>> XMLHelper xmlHelper = new XMIHelperImpl(xmlResource);
>>> String packagePrefix = xmlHelper.getPrefix(oldEPackage);
>>> return xmlHelper.getNamespaceURI(packagePrefix);
>>> }
>>>
>>>
>>> Really need some advice, I'm stuck :P
>> It sounds like content types are the perfect fit... Here's an example:
>
>> <extension
>> point="org.eclipse.core.runtime.contentTypes">
>> <content-type
>> base-type="org.eclipse.emf.ecore.xmi"
>> file-extensions="ecore"
>> *id="org.eclipse.emf.ecore"*
>> name="%_UI_Ecore_content_type"
>> priority="normal">
>> <describer
>
>>
> class=" org.eclipse.emf.ecore.xmi.impl.RootXMLContentHandlerImpl$Des criber ">
>
>> <parameter
>> name="namespace"
>> value="http://www.eclipse.org/emf/2002/Ecore">
>> </parameter>
>> <parameter
>> name="kind"
>> value="xmi">
>> </parameter>
>> </describer>
>> </content-type>
>> </extension>
>
>> <extension
>> point="org.eclipse.emf.ecore.content_parser">
>> <parser
>
>> class="org.eclipse.emf.ecore.xmi.impl.EcoreResourceFactoryImpl "
>> *contentTypeIdentifier="org.eclipse.emf.ecore"*>
>> </parser>
>> </extension>
>
>
>>>
>>> /Joachim
>>>
>>> Ed Merks wrote:
>>>
>>>> Joachim,
>>>
>>>> In the end, you really do need to read the resource, so why not
>>>> just read it off to the side to get the information? Maybe it will
>>>> help if I understand why you need this because perhaps there's a
>>>> better way.
>>>
>>>
>>>> Joachim Rietz wrote:
>>>>> Hi,
>>>>> See comments below.
>>>>>
>>>>> /Joachim
>>>>>
>>>>> Matthias Schoettle wrote:
>>>>>
>>>>>> Hi Joachim,
>>>>>
>>>>>>> Yes, I know about the "eNS_URI" field, but I can't use that one
>>>>>>> since the nsURI I want to retrieve is the one for the "old"
>>>>>>> model resource. The "eNS_URI" field is for the "new" model...
>>>>>
>>>>>> So you don't have the generated model for the old model anymore?
>>>>>> Can't you load the old model ecore file and retrieve the
>>>>>> namespace URI there?!
>>>>> No, not in runtime. Only the new one and ecore2xml mapping file.
>>>>> However, I found the XMLHelper class, might be something to use
>>>>> for resource parsing... Anyone who have tried it? Is this a good
>>>>> way to proceed?
>>>>> This one is instanciated by new XMIHelperImpl(xmlResource) and
>>>>> contains a getNamespaceURI() method...
>>>>>
>>>>>>> BTW: About the ecore2ecore I've used the wiki recipe;
>>>>>>> http://wiki.eclipse.org/EMF/Recipes#Recipe:_Data_Migration
>>>>>>> and that worked well for me.
>>>>>>> I have a command to trigger the transformation. What the command
>>>>>>> does is to first load the "old" resource with extended meta
>>>>>>> data; xmlResource.load(extendedMetaDataMap), and then save it;
>>>>>>> xmlResource.save(null).
>>>>>>> One important thing I noticed was to NOT use the same extended
>>>>>>> meta data for the save. Passing the same extended meta data at
>>>>>>> save results in a re-transformation of model meaning that you
>>>>>>> get the "old" model again ;o
>>>>>
>>>>>> I tried out the recipe but I always got the old model ;-)
>>>>>> But this might be because I am trying to export one model into
>>>>>> the other.
>>>>>
>>>>>> Do you use no extended meta data when saving or just (an)other
>>>>>> extended meta data?
>>>>> I use extended meta data at load but no extended meta data at
>>>>> save, just null argument to save().
>>>>>
>>>>>> Matthias
>>>>>
>>>>>
>>>
>>>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Apr 19 18:51:22 GMT 2024
Powered by FUDForum. Page generated in 0.03818 seconds |
] 
Search
Help
Register
Login
Home
