[news.eclipse.modeling.mdt.uml2] Re: Preserving uuid to xmi:id mapping c

["Kenn Hussey" <Kenn.Hussey@xxxxxxxxxxxxxxx>]

Piergiuseppe,

To be clear, you are dealing with URI fragments in both cases - the URI 
fragment is the portion of the URI that identifies an object within a 
resource. In the case of the (default) UML2 resource implementation, UUIDs 
are used as URI fragments; in Ecore, path-based strings are used.

For an example of how to call the converter programmatically, take a look at 
the ConvertToEcoreModelAction class in the UML2 examples plug-in or perhaps 
even the define(*) methods on ProfileOperations in 
org.eclipse.uml2.uml.internal.operations. Note that the converter can be 
used to look up target objects after the conversion is done by calling 
doSwitch(Object) again with the source object. In order to use XMI IDs for 
your Ecore models, you'll need to use a resource implementation that makes 
use of XMI IDs (or even UUIDs) instead of the default path-based convention 
used by the default Ecore resource implementation; you could even use the 
UML2 resource implementation, for that matter. An example of how to set the 
IDs for elements can be found in the ConvertModelAction, also in the UML2 
examples plug-in...

Kenn

"Piergiuseppe Spinelli" <piergiuseppe.spinelli@xxxxxx> wrote in message 
news:aec33d4c1e1830630600b6f2487f8e99$1@xxxxxxxxxxxxxxxxxx
> Kenn Hussey wrote:
>
> Kenn, many thanks for your answer
>
>> Piergiuseppe,
>
>> Given that UUIDs are supposed to be globally unique (that's why they're 
>> useful), I'm not sure it would be a good idea to assign the IDs of UML 
>> elements to the resulting Ecore elements
> Yes, I get your point. There could be different options here:
> - setting in ecore alternative ids "generated" by the original ones in UML 
> (i.e. adding a prefix) (at the end it is sufficient for the xmi:id to be 
> unique in the document or in the context of use)
> - do not use at all ids but URI fragments for mapping both the sides (as 
> you sugest, if I undertend) .
>
> The 2d options would be the most confortable one, but it seems to me it is 
> a little sensible to some kinds of changes (i.e. how it behaves when e 
> Class or Property is renamed, or a Class is moved to another package?)
>
> (although it would be possible by
>> calling the conversion utility programmatically, using a custom resource 
>> to load the Ecore model, and setting the XMI IDs of the Ecore elements 
>> based on the UML element on which they were based).
>
> Could you address me to some doc or sample?
>
> I would suggest producing a
>> mapping from UML element URI fragment (GUID) to Ecore element URI 
>> fragment (name-based path) by processing the map that is returned after 
>> the conversion and doing a reverse look-up to assign the desired IDs to 
>> UML elements if/when the Ecore representation is ever converted back to 
>> UML...
>
> Many thanks, I will do some test in this direction
>
>> Kenn
>
>> "Piergiuseppe Spinelli" <piergiuseppe.spinelli@xxxxxx> wrote in message 
>> news:66dcd6dc89d0595eed9e551934c1185b$1@xxxxxxxxxxxxxxxxxx
>>> Hi,
>>>
>>> I'm building an EMF based Eclipse application and I am currently using 
>>> the existing UML to EMF converter from the ide.
>>>
>>> How can I preserve the uuids in the original uml file forcing them to be 
>>> the xmi:id of the generated EClasses, and EStructuralFeatures?
>>>
>>> My UML tool assures to preserve the same uuid for the same element (even 
>>> if it is, let's say, moved to another package) across different exports, 
>>> so using uuids it is possible to perform more accurated comparisons of 
>>> generated eCore models that, i.e., do not exange a moving operation for 
>>> two unrelated operations (delete of the existing element and creation of 
>>> a new one).
>>>
>>> Thank for any help
>
>