Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 356318

Summary: Properties in input model are set to null
Product: [Modeling] MMT.ATL Reporter: Eszter Hofmann <eftike>
Component: EngineAssignee: mmt-atl.toolkit-inbox <mmt-atl.toolkit-inbox>
Status: NEW --- QA Contact:
Severity: normal    
Priority: P3 CC: william.piers
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Windows 7   
Whiteboard:

Description Eszter Hofmann CLA 2011-08-31 08:48:51 EDT
I have a transformation, which has as input and output the same metamodel (but I don't use refining mode). In my metamodel I have A, B, C classes: B extends A and C has a property p of type A. I wrote a transformation rule A2A and I didn't write a separate rule to transform B. My C2C transformation is:
rule C2C 
{
   from s : base!C
   to t : base!C {
      p <- s.p
   }
}

If in my input model p is instance of B then the transformer sets in the original model p to null!! In the output model p is set to the p from the original model.

If I am not using refining mode, under NO circumstances should the transformer make any changes on my input model, especially without any warning/error message!
Comment 1 Eszter Hofmann CLA 2011-08-31 08:51:33 EDT
I was executing my ATL transformation headless.
Comment 2 William Piers CLA 2012-03-16 05:47:35 EDT
The fact that the 'B' element moves from the input to the source model is because p is probably a containement: an EObject cannot be contained twice inside of the same EMF ResourceSet.
The modification of the input EMF Resource is caused by EMF when setting the output reference... as the input/output resources are loaded inside of the same ResourceSet.

ATL - non refining -, when launched in standard ways (launch configurations, ATL plugins) never saves changes mades on the input model, only saves ("extract") the output resource. But if you directly treat with EMF Resources, or save both input and output resources, then you shall encounter the behaviour you mention.

At this time I can only suggest a few workarounds:
- putting an eAdapter on the input resource before the transformation which throws an exception when the resource changes
- make a copy of the input resource before the transformation (this way the 'B' element will be in both input and output resources)