[cs2as] Clarify/diagnose element/model import confusions

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 453309 | | Status | NEW | | Importance | P3 normal | | Reported | Nov 26, 2014 08:33 EDT | | Modified | Sep 09, 2017 13:54 EDT | | Blocks | 453323 | | See also | 522060 | | Reporter | Adolfo Sanchez-Barbudo Herrera |

Description

Setup:\ OCL and QVTd master branches

I'll attach a patch with a demonstrating test case

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Nov 26, 2014 08:35

Created attachment 248953 Demonstrating test case

:notepad_spiral: clipboard.txt

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Nov 26, 2014 08:37

Additional notes:

• Workaround: remove the type of the MappingLoop iterator
• If you save the AS (qvtias), the iterator is serialised with the correct type [hence, not sure why that error appears in the editor]

[eclipse-ocl-bot]

By Ed Willink on Nov 26, 2014 09:35

Chnaging the imports to any of

import classes : 'Classes.ecore#/';\ import classescs : 'ClassesCS.ecore#/';\ import classescstraces : 'ClassesCS2AS.ecore#/';

or

import 'Classes.ecore';\ import 'ClassesCS.ecore';\ import 'ClassesCS2AS.ecore';

or

import 'Classes.ecore'::;\ import 'ClassesCS.ecore'::;\ import 'ClassesCS2AS.ecore'::*;

fixes the problem.

Equally chnaging

classescs::PackageCS

to

classescs::classescs::PackageCS

fixes the problem.

So the editor is basically correct.

Probably need a warning for an aliased model rather than element import. Maybe model imports can be discontinued.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Nov 26, 2014 10:55

Hi Ed,

Thanks for pointing out other workarounds. They have been enlightening.

I think that the bottom line is that the name used in the import is occluding the name of the package.

To me the name is needed, in the case you are importing different meta-models whose main package has the same name. The import name might be used to disambiguate.

So I suggest that the warning might be on the name used for model imports, in the case that it corresponds with the name/s of the main package/s (i.e. when a occlusion occurs).

On the other hand, I think there is still an inconsistency/ies:\ a) Why the "in" expression doesn't complain (e.g. classescs::PackageCS.allInstances()) ?.\ b) Shouldn't the TypedModel definition used in the transformation also complain ?

More concerns/thoughts:

• Can the name of an import occlude a subpackage?
• Would subpackage accesses need to be fully-qualified?
• What if an import name is used with ::'*' ? Probably a warning.