Eclipse Community Forums: EMF » Missing "xmi:id" in containment references serialization

Help

Home

Home » Modeling » EMF » Missing "xmi:id" in containment references serialization

Show: Today's Messages :: Show Polls :: Message Navigator

Missing "xmi:id" in containment references serialization [message #1779221]

Thu, 04 January 2018 07:49

Michele Tucci

Messages: 3
Registered: January 2018

Junior Member

Hi,

when a model (in this case, generated by an ATL transformation directly assigning the __xmiID__ attribute) is serialized, "xmi:id" are missing in containment references.

An example:

<?xml version="1.0" encoding="ISO-8859-1"?>
<SM:StateMachine xmi:version="2.0" xmlns:xmi="htp://www.omg.org/XMI" xmlns:SM="urn:SimpleStateMachine.ecore" xmi:id="270">
  <ownedState name="Begin Installation"/>
  <ownedState name="Memory Low"/>
  <ownedState name="Disk Error"/>
  <ownedState name="Install Software"/>
</SM:StateMachine>

As you can see, "xmi:id" is correctly serialized for the StateMachine element but not for State elements nested by means of the ownedState reference.

When the very same State elements are added to the model without referencing them, the result is what I expect:

<?xml version="1.0" encoding="ISO-8859-1"?>
<xmi:XMI xmi:version="2.0" xmlns:xmi="htp://www.omg.org/XMI" xmlns:SM="urn:SimpleStateMachine.ecore">
  <SM:State xmi:id="256" name="Memory Low"/>
  <SM:State xmi:id="239" name="Disk Error"/>
  <SM:State xmi:id="225" name="Install Software"/>
  <SM:State xmi:id="1" name="Begin Installation"/>
  <SM:StateMachine xmi:id="270"/>
</xmi:XMI>

When I override the useUUIDs() method of XMIResourceImpl to return true, nothing changes.

Is there a reason why "xmi:id" are missing from containment references?
Is there a way to change this behavior?

Thanks.

Report message to a moderator

Re: Missing "xmi:id" in containment references serialization [message #1779271 is a reply to message #1779221]

Thu, 04 January 2018 16:13

Ed Willink

Messages: 7670
Registered: July 2009

Senior Member

Hi

I would ask the opposite question; why are redundant xmi:id values there at all, since they are probably allocated lazily according to need?

It may well be that the ones you see are a side effect of something different. I doubt that containment has anything to do with it. I'm not sure where your xmi:id values come from since the EMF default is a multi-character UUID.

You can force the 'lazy' generation of xmi:id by traversing your model get the xmi:id of each element just before you save it.

Regards

Ed Willink

Report message to a moderator

Re: Missing "xmi:id" in containment references serialization [message #1779272 is a reply to message #1779271]

Thu, 04 January 2018 16:34

Michele Tucci

Messages: 3
Registered: January 2018

Junior Member

Thank you for your fast response.

"xmi:id" values are generated on purpose by an ATL transformation.
The problem was the overriding of the useUUIDs() method inside the code that executes the ATL transformation (the code is generated by the ATL plugin).
The solution is to override the newElement method of the EMFModel class:

ModelFactory xmifactory = new EMFModelFactory() {
	@Override
	public IModel newModel(IReferenceModel referenceModel) {
		return new EMFModel((EMFReferenceModel)referenceModel, this) {
			@Override
			public Object newElement(Object metaElement) {
				Resource mainResource = getResource();
				if (mainResource == null) {
					mainResource = new XMIResourceImpl(URI.createURI("new-model")) {
						@Override
						protected boolean useUUIDs() {
							return true;
						}
					};
					setResource(mainResource);
				}
				EClass ec = (EClass)metaElement;
				EObject ret = null;
				ret = ec.getEPackage().getEFactoryInstance().create(ec);
				mainResource.getContents().add(ret);
				return ret;
			}
		};
	}
};

Report message to a moderator

Previous Topic:	Reloading the resources into the application
Next Topic:	Maven Repository for Jars from Eclipse Oxygen (EMF 2.13)

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Sep 19 09:10:59 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter