Home » Modeling » EMF » Problem when copying both a model (stereotypes) and its meta-model (profile definition)
| Problem when copying both a model (stereotypes) and its meta-model (profile definition) [message #422187] |
Mon, 25 August 2008 11:34  |
|
Hi,
I have problems with EMF when trying to copy UML models with stereotypes
and profiles. [I don't think the underlying issue is specific to UML,
but if it is, feel free to follow-up in the uml2 group.]
Initially I have a UML model Main.uml, with package P and a class P::C.
I also have a UML profile MyProfile in MyProfile.uml. P has a profile
application for MyProfile, and C has the stereotype S (from MyProfile).
What I am trying to do is to make a copy of P for export purposes. The
exported version should contain P, all its contents and dependencies so
as to be self-contained (no dependency to the original resources).
- Copying P and C works just fine.
- Copying the profile application requires copying the whole profile
definition (by transitive dependency), but that's OK, and it works
fine.
- Copying the stereotypes also works, but the stereotypes copies are
considered instances of the original profile model (which is their
meta-model), not the copied/exported version.
I end up with an unwanted dependency to the original MyProfile.uml in
the exported resource, through the xsi:schemaLocation used for the
copied stereotypes. Basically, in the exported version I have:
<xmi:XMI ... xsi:schemaLocation="http:///schemas/MyProfile
MyProfile.uml#42">
where I would need:
<xmi:XMI ... xsi:schemaLocation="http:///schemas/MyProfile #42">
so that the exported stereotypes are considered instances of the
exported (local) version of the profile (it has the same ID).
I tried using ResourceSet.getURIConverter().getURIMap() (with an entry
for MyProfile.uml#42 -> #42), but it does not seem to be taken into
account during the XML serialization, at least for the
xsi:schemaLocation.
Looking into the XML serialization code, I found line 846 of
XMLSaveImpl.addNamespaceDeclarations() (from EMF 2.4.0) which seems to
be the place where the URI/location is determined:
String location = javaImplementationLocation == null ?
helper.getHREF(ePackage) : javaImplementationLocation;
location = convertURI(location);
Apparently this code does not take the ResourceSet's URIConverter into
account. Manually editing the "location" variable at this point in the
debugger gives me the correct result.
So, my questions are:
- Is this a bug in EMF? Should the xsi:schemaLocation honor the settings
in the URIConverter?
- Is there another way to control the schemaLocation mapping?
- Am I wrong in focusing on schemaLocation and is there a better way to
do what I want?
Pierre-Charles David - Obeo
Need training or professional services for Sirius?
http://www.obeodesigner.com/sirius
|
|
|
| Re: Problem when copying both a model (stereotypes) and its meta-model (profile definition) [message #422194 is a reply to message #422187] |
Mon, 25 August 2008 13:20  |
 Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Pierre-Charles,
Comments below.
Pierre-Charles David wrote:
> Hi,
>
> I have problems with EMF when trying to copy UML models with stereotypes
> and profiles. [I don't think the underlying issue is specific to UML,
> but if it is, feel free to follow-up in the uml2 group.]
If it gets really specific to UML, I'm not likely to be able to help...
>
> Initially I have a UML model Main.uml, with package P and a class P::C.
> I also have a UML profile MyProfile in MyProfile.uml. P has a profile
> application for MyProfile, and C has the stereotype S (from MyProfile).
>
> What I am trying to do is to make a copy of P for export purposes. The
> exported version should contain P, all its contents and dependencies so
> as to be self-contained (no dependency to the original resources).
> - Copying P and C works just fine.
And what exactly do you mean by coping. EcoreUtil.copy? Copying files?
> - Copying the profile application requires copying the whole profile
> definition (by transitive dependency), but that's OK, and it works
> fine.
> - Copying the stereotypes also works, but the stereotypes copies are
> considered instances of the original profile model (which is their
> meta-model), not the copied/exported version.
The copier doesn't deal directly with copying a meta model along with
transforming instances from the original meta model to the copied
metamodel. You could specialize a Copier that does that because there
are hooks for which Ecore class/feature to when creating the copy.
>
> I end up with an unwanted dependency to the original MyProfile.uml in
> the exported resource, through the xsi:schemaLocation used for the
> copied stereotypes. Basically, in the exported version I have:
>
> <xmi:XMI ... xsi:schemaLocation="http:///schemas/MyProfile
> MyProfile.uml#42">
>
> where I would need:
>
> <xmi:XMI ... xsi:schemaLocation="http:///schemas/MyProfile #42">
>
> so that the exported stereotypes are considered instances of the
> exported (local) version of the profile (it has the same ID).
>
> I tried using ResourceSet.getURIConverter().getURIMap() (with an entry
> for MyProfile.uml#42 -> #42), but it does not seem to be taken into
> account during the XML serialization, at least for the
> xsi:schemaLocation.
>
> Looking into the XML serialization code, I found line 846 of
> XMLSaveImpl.addNamespaceDeclarations() (from EMF 2.4.0) which seems to
> be the place where the URI/location is determined:
>
> String location = javaImplementationLocation == null ?
> helper.getHREF(ePackage) : javaImplementationLocation;
> location = convertURI(location);
>
> Apparently this code does not take the ResourceSet's URIConverter into
> account.
The URI converter is used for opening streams, not for converting things
before they are saved. Whatever URIs are one the resource is what's
used for saving.
> Manually editing the "location" variable at this point in the
> debugger gives me the correct result.
>
> So, my questions are:
> - Is this a bug in EMF? Should the xsi:schemaLocation honor the settings
> in the URIConverter?
No. The mapping is for going from logical to physical when interpreting
what a URI should denote, not for the reverse.
> - Is there another way to control the schemaLocation mapping?
Not without using a DocumentRoot.
> - Am I wrong in focusing on schemaLocation and is there a better way to
> do what I want?
It sounds like as part of copying you needed to copy the profile and
needed to ensure that the instances of the profile when copied use the
copied profile model.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Problem when copying both a model (stereotypes) and its meta-model (profile definition) [message #422197 is a reply to message #422194] |
Mon, 25 August 2008 13:51 |
|
Ed Merks a écrit :
> Pierre-Charles,
>> - Copying P and C works just fine.
> And what exactly do you mean by coping. EcoreUtil.copy? Copying files?
I use CopyCommands, followed by AddCommands to put the copies in a
different resource.
>> - Copying the profile application requires copying the whole profile
>> definition (by transitive dependency), but that's OK, and it works
>> fine.
>> - Copying the stereotypes also works, but the stereotypes copies are
>> considered instances of the original profile model (which is their
>> meta-model), not the copied/exported version.
> The copier doesn't deal directly with copying a meta model along with
> transforming instances from the original meta model to the copied
> metamodel. You could specialize a Copier that does that because there
> are hooks for which Ecore class/feature to when creating the copy.
You mean Copier#getTarget(EClass) and Copier#getTarget(EStructuralFeature)?
>> Apparently this code does not take the ResourceSet's URIConverter into
>> account.
> The URI converter is used for opening streams, not for converting things
> before they are saved. Whatever URIs are one the resource is what's
> used for saving.
OK.
>> - Is there another way to control the schemaLocation mapping?
> Not without using a DocumentRoot.
Can you elaborate? I don't know this mechanism.
XMLTypeDocumentRoot#getXSISchemaLocation() looks promising, but I don't
know how/where to use it.
>> - Am I wrong in focusing on schemaLocation and is there a better way to
>> do what I want?
> It sounds like as part of copying you needed to copy the profile and
> needed to ensure that the instances of the profile when copied use the
> copied profile model.
Yes, that's exactly what I need, but my question is how to do this?
Pierre-Charles David - Obeo
Need training or professional services for Sirius?
http://www.obeodesigner.com/sirius
|
|
|
| Re: Problem when copying both a model (stereotypes) and its meta-model (profile definition) [message #422199 is a reply to message #422197] |
Mon, 25 August 2008 14:02 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Pierre-Charles,
Comments below.
Pierre-Charles David wrote:
> Ed Merks a écrit :
>> Pierre-Charles,
>>> - Copying P and C works just fine.
>> And what exactly do you mean by coping. EcoreUtil.copy? Copying files?
>
> I use CopyCommands, followed by AddCommands to put the copies in a
> different resource.
I wouldn't have expected any of this would need to be undoable...
>
>>> - Copying the profile application requires copying the whole profile
>>> definition (by transitive dependency), but that's OK, and it works
>>> fine.
>>> - Copying the stereotypes also works, but the stereotypes copies are
>>> considered instances of the original profile model (which is their
>>> meta-model), not the copied/exported version.
>> The copier doesn't deal directly with copying a meta model along with
>> transforming instances from the original meta model to the copied
>> metamodel. You could specialize a Copier that does that because
>> there are hooks for which Ecore class/feature to when creating the copy.
>
> You mean Copier#getTarget(EClass) and
> Copier#getTarget(EStructuralFeature)?
Yes.
>
>>> Apparently this code does not take the ResourceSet's URIConverter into
>>> account.
>> The URI converter is used for opening streams, not for converting
>> things before they are saved. Whatever URIs are one the resource is
>> what's used for saving.
>
> OK.
>
>>> - Is there another way to control the schemaLocation mapping?
>> Not without using a DocumentRoot.
>
> Can you elaborate?
A DocumentRoot is something you only get with XML Schema-based models.
> I don't know this mechanism.
> XMLTypeDocumentRoot#getXSISchemaLocation() looks promising, but I
> don't know how/where to use it.
It's not really applicable for UML...
I think if you get the copied profile thing correct and set the
appropriate URI on its resource, you'll get what you want and this won't
be an issue.
>
>>> - Am I wrong in focusing on schemaLocation and is there a better way to
>>> do what I want?
>> It sounds like as part of copying you needed to copy the profile and
>> needed to ensure that the instances of the profile when copied use
>> the copied profile model.
>
> Yes, that's exactly what I need, but my question is how to do this?
I think you'd copy the profile file. The Copier itself is an instance
of a map, so once you've copied the profile, you have exactly the map
you need for the getTarget methods so that the copied instance be
created with the copied profile instead of just as a copy according to
the original profile.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Problem when copying both a model (stereotypes) and its meta-model (profile definition) [message #422202 is a reply to message #422199] |
Mon, 25 August 2008 14:45 |
|
Ed Merks a écrit :
>>> It sounds like as part of copying you needed to copy the profile and
>>> needed to ensure that the instances of the profile when copied use
>>> the copied profile model.
>>
>> Yes, that's exactly what I need, but my question is how to do this?
> I think you'd copy the profile file. The Copier itself is an instance
> of a map, so once you've copied the profile, you have exactly the map
> you need for the getTarget methods so that the copied instance be
> created with the copied profile instead of just as a copy according to
> the original profile.
Yes, that's what I had in mind from the hints you gave. Thanks for the help.
Pierre-Charles David - Obeo
Need training or professional services for Sirius?
http://www.obeodesigner.com/sirius
|
|
|
Goto Forum:
Current Time: Fri Apr 26 09:01:59 GMT 2024
Powered by FUDForum. Page generated in 0.03092 seconds |
] 
Search
Help
Register
Login
Home
