Bugzilla – Full Text Bug Listing
| Summary: | [environment] Diagnose and workaround synonym meta-models | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Modeling] OCL | Reporter: | Ed Willink <ed> | ||||
| Component: | Core | Assignee: | OCL Inbox <mdt-ocl-inbox> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | Angel.Roman, Ed.Merks | ||||
| Version: | 3.0.0 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows Vista | ||||||
| See Also: | https://bugs.eclipse.org/bugs/show_bug.cgi?id=547835 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Ed Willink
Equally baffling for the user and not sensibly correctable by EMF is when the same meta-model is used statically by one aspect and dynamically by another. In this case the static version was not necessarily ever loaded as a resource so no form of ResourceSet or URIConverter processing will help. It must be meta-model tools that detect the schizophrenia. Created attachment 177685 [details]
Sample projects exhibiting an issue with what appears to be oclIsKindOf and meta model synonym
WORKSFORME. When I run the launch config on a Modeling EPP installation I get: "It is a Family". so oclIsKindOf has succeeded. I can see opportunities for confusion between family/Family as modeltype/Package/Class name. Under what circumstances does your example fail? Did you restart Eclipse to check that your failure was reproducible? I think I've seen QVTo caching old meta-models.
I've tried tried genmodelling and cannot make your ZIP go wrong.
I've disambiguated the family and it still works as
if(ro.oclIsKindOf(FamilyModel::FamilyClass) and
ro.oclIsKindOf(familyPackage::FamilyClass)) then
{
log("It is a Family");
...
which clarifies that both model-type and package qualification are working.
Your original newsgroup query concerned no response from
family.rootObjects()[Family::Family]->forEach(ro).
Family::Family is very suspect. Re-use of a name within its own namespace is at best ill-advised since many languages prohibit re-use so that A::A::A::A is A!
How OCL QVTo allows Family::Family is dubious; I strongly suspect it resolves to the model-type not the Class.
Whether M2M/QVTo correctly supports this corner of the spec is also dubious. But it looks as if M2M/QVTo is doing what I would expect. The problem was not that oclIsKindOf failed, but that no candidates where available for selection.
Angel: You probably want to configure your Bugzilla preferences to auto-add yourself as a CC for a Bugzilla you comment on. Further information reveals that the problem is reproducible in Debug mode only (Bug 324054 raised for this against M2M/QVTo). Concerns about static/dynamic mixing are handled by EMF's dynamicIsKindOf. This MDT/OCL bug remains open to handle the discussed diagnosis of meta-model schizophrenia. Another form of meta-model schizophrenia arises with xsi:schemaLocation. Fortunately this one only bites on developers, but bites hard. If the run-time workspace contains an old/stable/released copy of e.g. http://family/1.0 that is registered via an extension point, and the develoipment workspace contains e.g. platform:/resource/Family/Family.ecore, then a load of the following development workspace XMI: <?xml version="1.0" encoding="ASCII"?> <familyPfx:FamilyClass xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:familyPfx="http://family/1.0" xsi:schemaLocation="http://family/1.0 platform:/resource/Family/Family.ecore"/> loads the development workspace XMI against the run-time Ecore; the xsi:schemaLocation is ignored. This is not wrong since the xsi:schemaLocation is only a hint, but it is very unhelpful to developers who might hope to have a coherent development workspace using development resources. The problem is particularly confusing if the development Family.ecore differs from the run-time meta-model. In this case a ClassNotFoundException may arise while reading the XMI. Of course the development time workspace should never have incompatible meta-models with the same URI! But they do, because otherwise every URI reference has to be changed. NB Ecore.ecore has had many changes without ever changing its URI. Perhaps EMF should have a workspace preference option so that all model loading favours development-time over run-time resources. Developers could set it and get better behaviour. Normal use would be unaffected. It does seem nice to have an option to force the xsi:schemaLocation to be more than a hint. Got a similar problem when playing with Dresden's uml_wfrs.ocl and UML.ecore which has two different kinds of reference to the one meta-model;. Also XMLType.ecore which is auto-generated wrong. Pivot tries to cache a package URI to EPackage map, but these don't work until the wrong resource is read. This problem may go away with the pivot model, since all pivots are in a single ResourceSet and equi-URI packages are 'merged' so competing definitions are detectable/ignorable. (In reply to Ed Willink from comment #10) > This problem may go away with the pivot model The problem can never go away. Sometimes you even want both. e.g. using the installed Pivot for tooling that generates a new Pivot. StandaloneProjectMap now has conflict resolution strategies so that the appropriate handler can be configured. When working with OCL tooling the StandaloneProjectMap supports redirection of multiple variants of the saem nsURI to just one. Conflicts are diagnosed. The original problem was therefore fixed in so far as EMF allows years ago. Bug 547835 addresses the need to improve usability. |