Community
Participate
Working Groups
Build Identifier: 20100617-1415 (Summarizing thread from <vs-25A30F.14514313072010@news.eclipse.org>) With Eclipse Helios, UML Validation, e.g. in the example UML Editor, fails for certain model fragments with e.g. "The opposite features 'owner' of '<Trigger> s' and 'ownedElement' of '<Transition> k' do not refer to each other" or similar. Apart from owner/ownedElement, it at least also fails for namespace/ownedMember, e.g. for an InterfaceRealization in a Component. Reproducible: Always Steps to Reproduce: 1. Use the UML Editor to create a new UML model (or do so programmatically): + Model + Component + Interface Realization 2. Run UML Editor -> Validate 3. Observe validation error regarding opposite features namespace/ownedMember.
As discussed in the newsgroup, we assume (and have for years) the implicit container of an element is its owner, and the implicit container of a named element is also its namespace (if it's a kind of Namespace). In order to satisfy this new constraint, we'd either need to stop making this assumption and add a bunch of new subsets constraints to the metamodel to make it explicit, or else (perhaps more realistically) bypass the constraint for UML models. The "fix" (latter option above) has been committed to both the HEAD and R3_1_maintenance streams.
The fix is available builds at http://www.eclipse.org/modeling/mdt/downloads/?showAll=1&hlbuild=I201008301532&project=uml2#I201008301532 (3.2.0) and http://www.eclipse.org/modeling/mdt/downloads/?showAll=1&hlbuild=M201008301351&project=uml2#M201008301351 (3.1.1).
Hi Kenn, I'm looking at Helios SR1 with UML2 3.1.1, and I'm still seeing: The opposite features 'feature' of 'org.eclipse.uml2.uml.internal.impl.InterfaceImpl@3aff8399{platform:/resource/examples/CoCoME/cocome/CoCoME.uml#_MAPtEItuEd29vaKB72n5RA}' and 'featuringClassifier' of 'org.eclipse.uml2.uml.internal.impl.OperationImpl@7852fda6{platform:/resource/examples/CoCoME/cocome/CoCoME.uml#_MAPtGotuEd29vaKB72n5RA}' do not refer to each other Maybe there are other instances of this bug left? (And apologies for not being in a position to have tested the RCs.) Cheers, Volker
(In reply to comment #3) > Maybe there are other instances of this bug left? (And apologies for not being > in a position to have tested the RCs.) Yes, it appears that other occurrences of the problem still exist. :( Perhaps you could open a new issue for which we could provide a more comprehensive solution in UML2 3.2?
Closing for Indigo release.
