Community
Participate
Working Groups
Created attachment 244982 [details] No diamond arrow for a bi-directionnal reference with containment Steps to reproduce: . Create/Open an Entity diagram . Create two classes C1 and then C2 . Create a standard reference r_1_2 from C1 to C2 . Create a Containment reference r_2_1 from C2 to C1 . Set r_1_2 as the opposite of r_2_1 (properties view) . Set r_2_1 as the opposite of r_1_2 (properties view) -> KO : the containment diamond is not displayed. org.eclipse.emf.ecoretools.design.service.EReferenceServices.getEOppositeEReferences(EPackage, DSemanticDiagram) compute the list of bi-directionnal references. It take the first found EReference of each couple as main ref. So regarding the ref order (sorted by EClass and then by containment order in each EClass), the main ref / candidate used to build the DEdge is the containment EReference or the container EReference. So a solution is to add a specific StyleCustomization: . StyleCustomization feature:container . PropertyCustomization (by expr) targetArrow . PropertyCustomization (by expr) sizeComputationExpression
Another little issue (which could get its own bugzilla, but concerns bi-directionnal edges too). The direct edit seems to set the set name for both edge labels, I thing we could try to set first or both : ref1 or ref1 - ref2 for example).
See https://git.eclipse.org/r/30243 for the new style customization.
Thanks for your patch. I just merged it on the 2.0 stream, I will close this bug when it is merged on the master stream too.
Reported on master with commit http://git.eclipse.org/c/ecoretools/org.eclipse.ecoretools.git/commit/?id=2416feac2f90fb91975b9b6d9d5211f430876462
*** Bug 445224 has been marked as a duplicate of this bug. ***