Community
Participate
Working Groups
Stereotype applications have an irregular XMI structure and so traversals of the Model tree or a subtree omits the stereotype applications. Now that MDT/UML2 has EMFv support, a UMLTraversalStrategy is better hosted by MDT/UML2 rather than MDT/OCL which requires Stereotype traversal in order to correctly support profilr validation in Papyrus.
Created attachment 225251 [details] Implementation developed by MDT/OCL The following extension point is required to publish the attached: <extension point="org.eclipse.emf.validation.traversal"> <traversalStrategy class="org.eclipse.ocl.examples.pivot.uml.UMLTraversalStrategy" namespaceUri="http://www.eclipse.org/uml2/4.0.0/UML"> <eclass name="Model"/> </traversalStrategy> </extension>
It sounds like the org.eclipse.uml2.uml.validation package would be a suitable home for something like this... but looking at the attachment, I see references to things from example packages in OCL. If you can prepare a proper contribution (with things in the right places, etc.) I could consider committing it. Note that implementation you have attached also appears to iterate over applied stereotypes instead of stereotype applications... was that your intent?
(In reply to comment #2) > I see references to things from example packages in OCL. The only OCL reference is the current package in which the source was developed. > Note that implementation you have attached also appears to iterate over > applied stereotypes instead of stereotype applications... was that your > intent? Ah! Not properly tested; Bug 397518 is making life difficult for me. I was expecting to have difficulty from the pseudo-objects and was pleasantly surprised/confused to see StereotypeImpl.
Created attachment 225277 [details] Patch for org.eclipse.uml2.uml.validation It would be useful to have Christian's comments before committing this. ?? Is a TraversalStrategy needed for every possible UML nsURI ??
Hi, Ed, Until we have Gerrit enabled, I will need you to sign off your patch in this bug, so that I may push your contribution to Eclipse. According to the Eclipse Wiki, it is sufficient that you comment with a statement like This contribution complies with http://www.eclipse.org/legal/CoO.php Thanks!
(In reply to Christian W. Damus from comment #5) > it is sufficient that you comment with a statement like > > This contribution complies with http://www.eclipse.org/legal/CoO.php This contribution complies with http://www.eclipse.org/legal/CoO.php A lot has happened in the intervening 9 months. In particular Papyrus validation has evolved to avoid suppressing EValidators. Various difficulties have caused me to lose confidence about EMFv/UML/OCL integration. I was never very comfortable with the fudges necessary to workaround the lack of EMFv extensibility; hence my original comment recommending review by C.Damus. It would be good to look at all emfv extension points in GIT\org.eclipse.ocl\examples\org.eclipse.ocl.examples.pivot\plugin.xml. Unfortunately this was not committed for Kepler so MDT/OCL had to ship it. We now have a migration issue; hopefully trivial, but is it guaranteed that no user will have both a MDT/OCL and an MDT/UML registration? It would be good to check that they can co-exist. Need an MDT/OCL Bugzilla as soon as this is pushed to master on MDT/UML2.
(In reply to Ed Willink from comment #6) > > This contribution complies with http://www.eclipse.org/legal/CoO.php Thanks. > A lot has happened in the intervening 9 months. In particular Papyrus > validation has evolved to avoid suppressing EValidators. Various > difficulties have caused me to lose confidence about EMFv/UML/OCL > integration. > > I was never very comfortable with the fudges necessary to workaround the > lack of EMFv extensibility; hence my original comment recommending review by > C.Damus. It would be good to look at all emfv extension points in > GIT\org.eclipse.ocl\examples\org.eclipse.ocl.examples.pivot\plugin.xml. Are you saying that you have new enhancement requests for UML2 based on the requirements of the OCL Examples? Do you have bugs to raise for EMFV? > Unfortunately this was not committed for Kepler so MDT/OCL had to ship it. > We now have a migration issue; hopefully trivial, but is it guaranteed that > no user will have both a MDT/OCL and an MDT/UML registration? It would be > good to check that they can co-exist. Need an MDT/OCL Bugzilla as soon as > this is pushed to master on MDT/UML2. We can't control what other projects do, nor how they might interfere with what the UML2 project does. Are you saying that you wish to withdraw this enhancement request? It seems generally useful to the UML2 user community. Note also that bug 402206 will factor the validation code and extensions out of the main UML run-time plug-in, which may help to address any integration issues.
(In reply to Christian W. Damus from comment #7) > (In reply to Ed Willink from comment #6) > > > > This contribution complies with http://www.eclipse.org/legal/CoO.php > > Thanks. > > > > A lot has happened in the intervening 9 months. In particular Papyrus > > validation has evolved to avoid suppressing EValidators. Various > > difficulties have caused me to lose confidence about EMFv/UML/OCL > > integration. > > > > I was never very comfortable with the fudges necessary to workaround the > > lack of EMFv extensibility; hence my original comment recommending review by > > C.Damus. It would be good to look at all emfv extension points in > > GIT\org.eclipse.ocl\examples\org.eclipse.ocl.examples.pivot\plugin.xml. > > Are you saying that you have new enhancement requests for UML2 based on the > requirements of the OCL Examples? Probably not for UML2. My uncertainties arise from the inadequacy of the EMFv-based approach taken by Papyrus that is really only suitable for pre-installed profiles such as MARTE or SysML. My Validity View approach looks much more promising and will ultimately allow the OCL debugger to be launched directly on the constraint/object pair that is causing the trouble. > Do you have bugs to raise for EMFV? There are a fair number already raised. > > > > Unfortunately this was not committed for Kepler so MDT/OCL had to ship it. > > We now have a migration issue; hopefully trivial, but is it guaranteed that > > no user will have both a MDT/OCL and an MDT/UML registration? It would be > > good to check that they can co-exist. Need an MDT/OCL Bugzilla as soon as > > this is pushed to master on MDT/UML2. > > We can't control what other projects do, nor how they might interfere with > what the UML2 project does. No but the failure to commit this in January causes the trouble now. It seems to me now that is it MDT/UML2's responsibility to avoid collision with the action it forced on MDT/OCL. > > Are you saying that you wish to withdraw this enhancement request? It seems > generally useful to the UML2 user community. Note also that bug 402206 will > factor the validation code and extensions out of the main UML run-time > plug-in, which may help to address any integration issues. I am far from clear that we are pursuing the best direction. Someone familiar with both UML2 and EMFv can judge better than me whether this functionality is appropriate. There were also some major profile/stereotype performance issues that got fixed for Kepler. My contribution needs to be checked to ensure that it isn't creating new bad issues. Checking for stereotypes is generally really bad news performance-wise.
(In reply to Ed Willink from comment #8) > No but the failure to commit this in January causes the trouble now. It > seems to me now that is it MDT/UML2's responsibility to avoid collision with > the action it forced on MDT/OCL. If any action was "forced" on a project by a feature that has never been and still is not provided by either UML2 or EMFV, then it was forced when EMFV and UML2 were first released together in the Callisto release several years ago. However, it strikes me as likely that applications such as Papyrus and other modeling tools built on UML2 have already registered their own traversal strategies for the UML metamodel, so introducing such a registration now would probably cause conflicts. I think it will be best to do what we did with the delegating constraint provider: provide an implementation of the traversal strategy for integrators (applications) to use as they see fit, registering it as is if that is sufficient for them, but not registering it in UML2. > > Are you saying that you wish to withdraw this enhancement request? It seems > > generally useful to the UML2 user community. Note also that bug 402206 will > > factor the validation code and extensions out of the main UML run-time > > plug-in, which may help to address any integration issues. > > I am far from clear that we are pursuing the best direction. Someone > familiar with both UML2 and EMFv can judge better than me whether this > functionality is appropriate. Right, as above, I think the registration in UML2 would be redundant at best and interfering at worst. It could be worth considering if UML goes to 5.0 with breaking API changes, which then forces integrators to re-evaluate their dependency anyways. > There were also some major profile/stereotype > performance issues that got fixed for Kepler. My contribution needs to be > checked to ensure that it isn't creating new bad issues. Checking for > stereotypes is generally really bad news performance-wise. It shouldn't perform worse than the label provider in the UML editor, which also finds the stereotypes of all elements in the model.
(In reply to Christian W. Damus from comment #9) > Right, as above, I think the registration in UML2 would be redundant at best > and interfering at worst. It could be worth considering if UML goes to 5.0 > with breaking API changes, which then forces integrators to re-evaluate > their dependency anyways. 5.0 would certainly solve the break, but with UML 2.5 not changing the metamodel beyond a couple of 'it-could-never-have-worked's maybe a major version isn't needed.
Kenn, I'll be interested in your opinion on the registration question and/or whether it is worth pursuing this enhancement under the circumstances.
(In reply to comment #10) > 5.0 would certainly solve the break, but with UML 2.5 not changing the metamodel > beyond a couple of 'it-could-never-have-worked's maybe a major version isn't > needed. Heh. I have yet to complete my analysis of the changes in UML 2.5, but at first glance the fact that the "standard" profile as once again been consolidated is likely a "breaking" change in Eclipse API parlance.
(In reply to comment #9) > I think it will be best to do what we did with the > delegating constraint provider: provide an implementation of the traversal > strategy for integrators (applications) to use as they see fit, registering it > as is if that is sufficient for them, but not registering it in UML2. +1
I have pushed a new branch bugs/397508 with two commits. Commit 6140836 is the original patch contribution modified only by applying the UML2 code formatter and updating file copyright statements. Commit 93665c2 follows it up with * reversion of the plugin.xml changes that registered the traversal strategy (leaving it still for applications to do this) * adding constructors for a bit more reusability by applications * adding some basic JUnit tests
The changes have been merged and pushed to the 'master' branch in git.
The changes are available in an integration build for 4.2.0.
(In reply to Christian W. Damus from comment #14) > * reversion of the plugin.xml changes that registered the traversal > strategy (leaving it still for applications to do this) We need to decide what we are doing here. Papyrus M6 alpha users are confused because profile validation does/doesn't work. A problem is that in M6 MDT/OCL registers the UMLTraversalStrategy for 4.0.0 but not 5.0.0 so old tests work, new tests fail. Since MDT/UML2 can provide the registration without dependency issues, I think it would be good if MDT/UML2 provided it for version 2/3/4/5.0.0 and MDT/OCL retracted its registration for just 4.0.0.
I believe the decision that was made was that applications would do the registration as needed. If MDT/OCL has taken it upon itself to do the registration, it needs to be updated to reference 5.0.0. Otherwise, a registration needs to be added in Papyrus.
(In reply to Kenn Hussey from comment #18) > I believe the decision that was made was that applications would do the > registration as needed. I'm not clear that was a decision; rather an inertia that made a change difficult without a major version change. We now have a major version change. > If MDT/OCL has taken it upon itself to do the > registration, it needs to be updated to reference 5.0.0. MDT/OCL could certainly be updated, but this gives us a strange behaviour. a) MDT/OCL not installed; UML Model Editor etc skip over stereotype applications. b) MDT/OCL installed; UML Model Editor etc process stereotype applications. > Otherwise, a registration needs to be added in Papyrus. a) a Papyrus plugin registration gives a similar with/without Papyrus UML inconsistency. b) a Papyrus programmatic registration gives a puzzling behaviour for add-on plugins that may sometimes bypass the registration. AFAICT Only plugin and standalone registration of the MDT/UML2-provided facility by MDT/UML2 can avoid user confusion.
(In reply to Ed Willink from comment #19) In the discussion of Papyrus bug 417062, we concluded that the best 'home' for integration of UML concerns with the EMF Validation project is an optional feature in the latter project. This would include: * registration of the UML-specific traversal strategy * integration of profile constraints in any language (not just OCL) * a UML profile for tagging constraints (esp. in profiles) with the extra metadata required by EMF Validation (severity, localizable message, evaluation mode, etc.) * possibly (depending on how the discussion settles) a stereotype in the aforementioned profile that lets elements be tagged as non-validatable or to include/exclude specific constraints * in the case of InstanceSpecifications, an extensibility hook that would let languages such as OCL apply to InstanceSpecifications the constraints defined on their classifiers It is obviously too late for this in the Luna release, but I plan to get the ball rolling with the EMF Validation team for the next release. This would pretty much obviate the need to do anything further in the UML2 project.
(In reply to Christian W. Damus from comment #20) > It is obviously too late for this in the Luna release, but I plan to get the > ball rolling with the EMF Validation team for the next release. This would > pretty much obviate the need to do anything further in the UML2 project. OK. So for Luna, I'll upgrade the OCL registrations. Hopefully the Pivot part of OCL will have a major version change for Mars so we can migrate the registrations then without affecting UML2 which perhaps won't need a major version change.
