Community
Participate
Working Groups
Build Identifier: IES 3.6, 20100611 If a parent client context, PCC, is set as 'default' and binds to namespace NS1, then it is expected that an extending client context, ECC, would inherit all constraints of the parent context. This currently works, given the constraints bound to PCC are bound via XML. Any constraints which are implicitly bound via the Nampespace at runtime, are not being inherited by the extending clients. Expected behaviour is that an extending client context will inherit all constraints bound to the parent context, whether they were explicitly or implicitly bound. Reproducible: Always Steps to Reproduce: 1)create a plugin that defines a constraintBinding, and declares a clientContext which extends a base context declared as default. <extension point = "org.eclipse.emf.validation.constraintBindings"> <clientContext default = "false" id = "org.example.subClientContext"> <selector class = "ExampleCientSelector"/> </clientContext> <binding category = "example" context = "org.example.subClientContext"> <extendClientContext ref = "com.ibm.xtools.modeler.validation.client"/> </extension> 2) make the selector class always return true... 3) create a validation project e.g.: File / New / Examples / RMP Plugins / Modeler Plugins / Model Validation 4) launch application 5) set a breakpoint in the JavaExample class 6) create a cyclic generalization and validate the model
I infer from bug 249496, comment 11, point (2), and the response in comment 12, that this is working as designed. In other words, clients should always bind their constraints to the context that they want to be part of. The use of the default context is, according to its author, discouraged. The documentation on the extendClientContext element in the constraintBindings extension point does not address what the expected behaviour should be with respect to inheriting constraints that are implicitly bound to a default context, one way or the other. I propose that the extension point documentation be updated to make this clear, as follows: "extendClientContext Since 1.3. References a client-context that the bound context extends. Conceptually, this declares that objects matching the referenced context also match my bound context. In practice, this means that my bound context inherits all of the explicit constraint bindings from the referenced context. This will not include any implicit constraint bindings if the referenced context is a default context. If my bound context wishes to include such implicit constraint bindings, it should itself be declared as a default context."
Eclipse EMF Validation is moving away from this bugs.eclipse.org issue tracker to https://github.com/eclipse/emf-validation. If this issue is relevant to you and still present in the latest release: * Create a new issue at https://github.com/eclipse/emf-validation/issues/. * Use as title in GitHub the title of this Bugzilla ticket (may include the bug number or not, at your own convenience) * In the GitHub description, start with a link to this bugzilla ticket * Optionally add new content to the description if it can helps towards resolution * Update bugzilla ticket * Add to "See also" property (up right column) the link to the newly created GitHub issue * Add a comment "Migrated to <link-to-newly-created-GitHub-issue>" * Set status as CLOSED MOVED All issues that remain open will be automatically closed next week or so. Then the Bugzilla component for EMF Validation will be archived and made read-only.
EMF Validation is in maintenance mode and has very few resources available. If you feel this issue is still relevant and important enough, and are willing to actively contribute yourself (or fund someone to work on it), please re-open on GitHub at https://github.com/eclipse/emf-validation/issues
