Community
Participate
Working Groups
Build ID: I20070222-0951 Steps To Reproduce: 1. Create the following Ecore: Invoice : EClass * lineItem : EReference [containment=false, lowerBound=0, upperBound=-1] ProductRegistry : EClass * product : EReference [containment=true, lowerBound=0, upperBound=-1] 2. Create an EMF model (.genmodel) for your Ecore. Observe that the "lineItem" GenFeature will have the Edit attributes "Child" and "Create Child" false. Meanwhile, the GenFeature for "product" will have "Child" and "Create Child" to true. 3. Generate Model/Edit code, and note that getChildrenFeatures(...) is generated for ProductRegistryItemProvider but not for InvoiceItemProvider. So far, so good. 4. Change the lineItem EReference to be containment=true. 5. Check your genmodel, and observe that the Child/Create Child attributes of lineItem will _not_ be changed to true. They have remained false. 6. To make sure, do a genmodel reload from the ECore. Right-click the ecore, say Reload... and load up your ecore. Child/Create Child are _still false_, despite the fact that this reference has containment=true. 7. Since getChildrenFeatures(...) will not have been generated, this containment relationship will _not_ display correctly in a TreeViewer utilizing the EMF.Edit framework. More information: It took me a long time to figure out that this was what was going on (debuged quite deep into EMF stack). I assume it would make sense for the genmodel to update these Child/Create Child attributes based upon changes to the containment attribute on EReference, but maybe this was overlooked in the code. (If you have a good reason why you don't do this update automatically, I'd be all ears.) Let me know if there are any issues reproducing it.
This is working as designed. The blanket policy for model reloads is that we only add or remove GenModel elements along with the corresponding Ecore model elements. Although the initial state of, say, a GenFeature depends on how the underlying EStructuralFeature is configured, the user is completely free to change attributes on the GenFeature, so we don't want to mess with it in any way after it's been created. We actually used to have special treatment for enabling or disabling containment on an EReference, but since we started allowing non-containment references and even attributes to be considered children features, it just didn't make sense anymore. Does this explanation seem reasonable? I'd like to close this bug as INVALID, since it is working as designed.
This makes sense (didn't know that non-containment EStructuralFeatures could be marked as child features). In GMF land, only containment relationships can be marked in child features, so I assumed the two projects were synced in this regard. Considering that the initial state of a GenFeature with containment is true for Child/Create Child, I think this particularly SNAFU I ran into needs some good documentation if it's going to remain as it is. This raises another question. I think I'm not alone in approaching the GenModel as follows: I'd like to customize the general options for the generator, like where output goes and what to supress, but I'd like the ECore-decorated parts of the GenModel (IOW, the GenFeatures and GenClasses) to otherwise be in sync with the ECore model, so I can evolve my ECore model and have the GenModel evolve with it, but preserve my customizations to how generation should occur. In the GenModel, just the root node and the decorations on "EPackage" should remain unchanged, but everything else is free to sync with the default behavior from the referenced Ecore. Wouldn't it be nice to offer this option, perhaps as part of the "Reload..." dialog? "Overwrite GenClasses and GenFeatures with Defaults?" or some such. This would simultaneously fix the "bug" I pointed out here, and increase usability for what I think is a common use case. Let me know what you think, Andrew
I'll change this to an enhancement request and change the summary to reflect what's requested. Instead of in the wizard, I suppose one could have a popup that does the same thing, but then folks might never find it and they'd expect undo to work.
*** Bug 329947 has been marked as a duplicate of this bug. ***
*** Bug 336969 has been marked as a duplicate of this bug. ***
