Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 329947 - Containment properties don't propagate from ecore to genmodel file after first save
Summary: Containment properties don't propagate from ecore to genmodel file after firs...
Status: CLOSED DUPLICATE of bug 186455
Alias: None
Product: EMF
Classification: Modeling
Component: Core (show other bugs)
Version: 2.5.0   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Ed Merks CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-10 15:39 EST by Glenview Jeff CLA
Modified: 2010-11-15 10:13 EST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Glenview Jeff CLA 2010-11-10 15:39:56 EST
Build Identifier: M20100211-1343

1. Create a simple meta-model in ecore editor that has an Eclass named A and a second one named B.  Add a container (0..*) of A to B, but leave the containment attribute set to false.
2. Save the meta-model.
3. Open up the genmodel file and note that the children, create children, etc. are false as they should be.
4. Return to the ecore file and change the containment attribute to true, then save it.
5. Open up the genmodel file and note that the children, create children, etc. are still false, but should be true.

I did notice that a workaround is to rename the Eclass from B to B2 and back to B.




Reproducible: Always

Steps to Reproduce:
1. Create a simple meta-model in ecore editor that has an Eclass named A and a second one named B.  Add a container (0..*) of A to B, but leave the containment attribute set to false.
2. Save the meta-model.
3. Open up the genmodel file and note that the children, create children, etc. are false as they should be.
4. Return to the ecore file and change the containment attribute to true, then save it.
5. Open up the genmodel file and note that the children, create children, etc. are still false, but should be true.

I did notice that a workaround is to rename the Eclass from B to B2 and back to B.
Comment 1 Stephane Begaudeau CLA 2010-11-12 16:42:16 EST
Is this an Acceleo bug ? With your description, all I can see is an EMF bug. If it is link to Acceleo in any way, please add more information to your description. Otherwise, I would advise you to see if this bug has not already been reported for EMF and if not to report your bug to the EMF section of the bugzilla.(Product: EMF, Component: I don't know maybe Edit or Core... you should look for another about the genmodel in the first place)

For the moment, I will close that bug, if you have any information indicating that Acceleo is involved in this and that we can improve in any way, add a comment here, and I will reopen the bug.
Comment 2 Glenview Jeff CLA 2010-11-12 16:53:01 EST
Forgive me for getting the tool wrong.  I'm new at MDSD/the EMF set of tools and I'm only just now beginning to understand the roles of each tool in the process
Comment 3 Laurent Goubet CLA 2010-11-15 04:47:12 EST
Hi Jeff,

This is indeed not an Acceleo bug. I don't think that this is an EMF Index bug either, I'm reaffecting to EMF Core so that Ed can see it (and blame me if it isn't a Core bug :p).

Also assigning to Ed.Merks@gmail.com in order to avoid spamming the m2t watchers.
Comment 4 Ed Merks CLA 2010-11-15 10:13:17 EST
This is working as designed.  The GenModel properties are *always* preserved, even in cases where you might not want that.   So once you create the GenModel, the properties are all initialized and will not change, regardless of what you change in the Ecore model.

*** This bug has been marked as a duplicate of bug 186455 ***