Bugzilla – Full Text Bug Listing
| Summary: | Generating Model Code for a Containment Reference fails to create a variable | ||
|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | E Bekker <ebekker4csc> |
| Component: | Edit | Assignee: | Dave Steinberg <davidms> |
| Status: | RESOLVED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 2.1 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 75933 | ||
I think you've accidentally marked the wrong end.
The parent-to-child relationship is a containment reference.
The child-to-parent reference is is a *container* reference.
Note that you should not do anything to mark to the latter -- it's derived from the former.
I've changed the two interfaces as follows, and now it works...
--8<--Parent.java-----
package testemf;
/**
* @model
* @generated
*/
public interface Parent {
/**
* @model type="Child" opposite="parent" containment="true"
*/
public java.util.List getChildren();
}
------>8--
--8<--Child.java-----
package testemf;
/**
* @model
* @generated
*/
public interface Child {
/**
* @model opposite="children"
*/
public Parent getParent();
}
------>8--
In addition to moving the containment, I also had to remove the extends clauses, since they'll be filled in by the generator, and you should only include types that you want to be explicitly extended in the model.
With these changes, it all works as expected. I'd say this is a case of bad error reporting, so I'll mark it as a duplicate of bug 104727 (would that I had the time to improve it now!).
*** This bug has been marked as a duplicate of 104727 ***
That did the trick, I guess I misinterpreted the directional intent of the attribute. Is there a listing of all the valid params to the @model annotation and their meanings? I did a search through EMF docs and could not find any central location. In the JavaDoc the attributes seem to be listed on the corresponding element type (i.e. EClass, EAttribute), but that does not actually give the name of the param (i.e. opposite, type, containment) and most don't have a description. Please see my response in the newsgroup to "EMF Java Annotations Reference?", dated January 13, 2006. The short answer is, no. There is an out-of-date list in the EMF book, and in that post, I added all of the new stuff. Taken together, you'll have a complete list. Sorry that our documentation is as lacking as our time! :) This could be handled as an Ecore constraint: container reference must be multiplicity-one. This could be handled as an Ecore constraint: container reference must be multiplicity-one. |
When I tested out a simple model with two classes, Parent and Child. Each has a EReference feature to the other, forming a many to one relationship via Parent.children, and Child.parent features. If I specify Child.parent as a containment="true" feature, when I generate the Model Code, it generates the proper EList getChildren() accessor in ParentImpl, that makes references to "children" instance variable, but does not generate the instance variable. I generated the EMF model by importing the following annotated Java code: --8<--Parent.java----- package testemf; /** * @model * @generated */ public interface Parent extends EObject { /** * @model type="Child" opposite="parent" */ public java.util.List getChildren(); } ------>8-- --8<--Child.java----- package testemf; /** * @model * @generated */ public interface Child extends EObject { /** * @model containment="true" opposite="children" */ public Parent getParent(); } ------>8-- After using the "EMF Model" wizard, importing the package containing these two, and then selecting the .genmodel and doing a "Generate Model Code" I get a ParentImpl that has compile errors. Note, that this problem exists in the latest 2.2 integration build as well. Also note, that if I get rid of the "containment=true" then it works ok, but of course the getChildren() accessor is different, since it generates code that does proxy dereference checking, and this also changes the semantics of the relationship.