Hi Mark! Thank you very much for your explanation, it was really helpful. I will try to change my code accordingly.
Best regards,
Arne
Am 05.03.2015 um 11:47 schrieb Mark Brörkens <mark.broerk...@itemis.de>:
> Hello Arne,
>
> I recently observed the same problem.
>
> It is related to a change in the ID management. In earlier releases RMF
> managed the ID that is used for referencing was part of the model.
> The value was read/modified by means of the API setIdentifier() and
> getIdentifier(). Using this approach we often ran into issues with respect to
> duplicated IDs.
> This happened if model elements were copied without updating its ID.
>
> In RMF 0.11.0 the intrinsic ID management (ID is stored as part of the model)
> was replaced by an extrinsic ID management (IDs are no longer stored in the
> model. Instead they are managed in the eObjectToIDMap of the XMLResource).
> This has the advantage, that copy activities automatically result in new IDs
> in the XML representation.
>
> The switch to the extrinsic ID is not yet fully implemented: The old API
> setIdentifier() and getIdentifier() is still there although the value in the
> model is no longer used for ID management. Only the values in the
> eObjectToIdMap of the resource are used as ID during serialization.
>
> Long story short:
> * don’t use the getIdentifier() or setIdentifier() API. This is a left over
> from the intrinsic ID management. This API should be removed from the RMF
> ReqIF API.
> * if you want to modify the ID you need to explicitly modify the
> eObjectToIdMap of the resource. For example like this:
>
> ResourceSet reqIFResourceSet = new
> XMLPersistenceMappingResourceSetImpl();
> XMLResource reqIFResource =
> (XMLResource)reqIFResourceSet.createResource(URI
> .createURI("out.reqif"));
> reqIFResource.setID(attributeDefinition, „attributeID“);
> …
> reqIFResource.getContents().add(reqIF);
> reqIFResource.save(null);
>
> Hope I could help.
>
>
> kind regards
>
> Mark
>
>
>
>
>
> --
> Mark Brörkens
> Softwarearchitekt, Projekt- und Produktmanager
>
> itemis AG
> Bertolt-Brecht-Platz 3
> 10117 Berlin
>
> Tel: +49 30 12089790
> Mobil: +49 151 61301259 (bevorzugt)
> Email: mark.broerk...@itemis.de
>
> http://www.itemis.de
> http://xing.to/mark_broerkens
> http://twitter.com/MarkBroerkens
>
>
> Rechtlicher Hinweis:
> Amtsgericht Dortmund, HRB 20621
> Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens
> Trompeter, Sebastian Neus
> Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer
> Fiorentino
>
> Am 05.03.2015 um 10:54 schrieb Arne Noyer <ano...@willert.de>:
>
>> Hello!
>>
>> I have already started the following discussion in the Eclipse Community
>> Forum (https://www.eclipse.org/forums/index.php/t/1026855/), but Michael
>> Jastram suggested to continue it in the dev list, as not every dev may read
>> the forum.
>>
>> Here is what the discussion is about:
>>
>>
>> I have just upgraded to version 0.11 and observed, that the behavior of
>> dealing with identifiers has changed. I used to manually set identifiers for
>> SpecObjects, SpecTypes and other elements. Is this still possible?
>> In my observation, it results in some problems.
>>
>> Consider the following code:
>>
>> Code: [Select all] [Show/ hide]
>> SpecObjectType result = ReqIF10Factory.eINSTANCE.createSpecObjectType();
>> result.setIdentifier("myIdentifier");
>>
>> // New identifier will be assigned automatically
>> documentRoot.getCoreContent().getSpecTypes().add(result);
>> String newRandomIdentifier = result.getIdentifier();
>>
>> // It's ok, the Identifier can still be set later
>> result.setIdentifier("myIdentifier");
>>
>>
>> When adding an element, like a SpecObjectType to a parent, it results in
>> automatically setting a new identifier now. After observing this, i thought
>> i will just change my code to set the identifier after adding an element to
>> a parent.
>> It looked fine at first glance and the identifier attribute of the object
>> was never changed later.
>> But when creating references from other elements to the object, for instance
>> a reference from a SpecObject to the SpecObjectType above, it results in
>> errors when persisting the model to a XMI file.
>>
>> Inside the XMI file, in the example above the SpecObjectType will be
>> persisted with the correct identifier="myIdentifier", but all the elements
>> who have a reference to it, still use the identifier for the reference as it
>> is automatically created. Setting the identifier does not affect this at all.
>> The same seems to apply to other element as well.
>>
>> Code: [Select all] [Show/ hide]
>> ...
>> <SPEC-OBJECT-TYPE IDENTIFIER="myIdentifier" ...>
>> ...
>>
>> <SPEC-OBJECT>
>> <TYPE>
>> <SPEC-OBJECT-TYPE-REF> "randomIdentifier" </SPEC-OBJECT-TYPE-REF>
>> </TYPE>
>> </SPEC-OBJECT>
>>
>>
>>
>> The question to this topic is: Is this behavior intended or is this a bug?
>> Is it not possible anymore to set my own identifiers by using the
>> setIdentifier() operations?
>>
>>
>> Michael already responded, that the behavior is intended, as you take
>> advantage of EMF keeping an index of all IDs.
>>
>> However, is it still possible to set identifiers somehow (and inform EMF
>> about updating the index with the IDs) or do i have to deal with it, that I
>> can not set the identifier myself?
>>
>>
>> Btw: Great job with the RMF and ProR :-)
>>
>>
>> Thank you very much in advance!
>>
>> Arne
>>
>>
>>
>>
>> _______________________________________________
>> rmf-dev mailing list
>> rmf-dev@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe from
>> this list, visit
>> https://dev.eclipse.org/mailman/listinfo/rmf-dev
>
> _______________________________________________
> rmf-dev mailing list
> rmf-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/rmf-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ rmf-dev mailing list rmf-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/rmf-dev
