-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inconsistent Profile URIs #71
Comments
By Kenn Hussey on Feb 17, 2015 09:36 (In reply to Ed Willink from comment #0)
The nsURI is auto-generated because the (EMF) package is auto-generated and the result must conform to EMF constraints.
The nsURI must be distinct for each new profile version to support migration of profile/stereotype data.
If a URI has been specified by the user, the expecation is that the user will change the URI appropriately if/when necessary based on what’s changed in the profile - just as we do with other EMG-generated models.
I hesitate to introduce such a warning when it’s not a required property in UML.
What do you mean by this? |
By Ed Willink on Feb 17, 2015 10:49 (In reply to Kenn Hussey from comment #1)
If Eclipse UML was 100% OMG compliant then I would agree, but in practice Eclipse UML is distorted by the use of Ecore, so a model that fails to fulfill the Ecore compatibility requirements merits a warning.
If the UML Package uri or nsURI Tag is "x" and the EPackage nsURI is "y" then I consider this to be an error that the user would like to know about rather than have to debug the downstream consequences of incompatible UML/Ecore representations. (These problems arise now because the Pivot-based Eclipse OCL now uses the UML model wherever possible ignoring the Ecore-isms. The Ecore-based Eclipse OCL used the Ecore and largely ignored the UML.) |
By Kenn Hussey on Feb 17, 2015 11:19 (In reply to Ed Willink from comment #2)
Ah, but not every UML model gets converted to Ecore...
This is actually an expected condition until the Ecore package is regenerated - the user could be in the process of editing the profile… |
By Ed Willink on Feb 17, 2015 12:13 (In reply to Kenn Hussey from comment #3)
Hence a warning rather than an error. Really easy to make the warning go away.
While I edit Java I have errors. No surprise. Why no diagnostic while editing UML? |
By Kenn Hussey on Feb 17, 2015 13:13 (In reply to Ed Willink from comment #4)
I think this would be an annoyance for modelers that never have the intention of ever converting to Ecore.
Validation in UML2 is currently only based on constraints defined in UML, and those are processed in batch, on demand. Changing this would be a non-trivial undertaking and would provide questionable ROI in UML2 when the more appropriate place for such conveniences is at the application level. |
| --- | --- |
| Bugzilla Link | 459606 |
| Status | NEW |
| Importance | P3 normal |
| Reported | Feb 10, 2015 15:53 EDT |
| Modified | Sep 14, 2017 04:09 EDT |
| Blocks | 459520 |
| See also | 522257, 522256 |
| Reporter | Ed Willink |
Description
OMG UML used not to have Package URIs.
Ecore GenModel has always mandated a well-formed nsURI.
OMG has gradually acquired Package URIs, first as a Tag then as a property.
Eclipse UML is a bit of a mess.
The UML model is permitted to have no URI in accordance with the UML 2.5 multiplicity, but a URI is auto-generated when defining a profile. Confusingly if the URI is null/blank, each autogenerated nsURI is distinct. But if the URI is defined each nsURI is the same.
This practice is particularly bad in the case of Bug 459605 where profile definitions erroneously creoss-reference.
Suggest: Package with null/blank URI is a validation warning.
Suggest: Profile with distinct Package URI / EPackage nsURI is a validation error.
The text was updated successfully, but these errors were encountered: