Open eclipse-ocl-bot opened 1 month ago
By Ed Willink on Sep 29, 2021 04:20
Attempting to tweeak the generator to accommodate the 'wrong' imprt is confusing, import is sometimes magically correct.
Bug 487217 agrees in regard to the non-nsURI import usage but is vague in its conclusion.
/org.eclipse.qvtd.pivot.qvtimperative/model/QVTimperative.ecore
has
all nsURI
/org.eclipse.qvtd.xtext.qvtimperative/model/QVTimperativeCS.ecore
has
The 'accurate' imports are probably the result of an auto-generation/rewrite since manual entry of a ...#P-... id is not easy.
By Ed Willink on Sep 29, 2021 13:02
(In reply to Ed Willink from comment #1)
Attempting to tweeak the generator to accommodate the 'wrong' imprt is confusing, import is sometimes magically correct.
/org.eclipse.qvtd.pivot.qvtimperative/model/QVTimperativeStructural.ecore
is
and is moved by the ResourceRenamer to
/org.eclipse.qvtd.pivot.qvtimperative/model/QVTimperative.ecore
where the ConstraintMerger corrupts the import to\
Problem is that ClassUtil.isRegistered is too simplistic in determining what is a GenModelled Resource. Old test is ResourceSet null, which is calling code order dependent. New test is that Resource URI is the same as a root EPackage nsURI. (Real resources have platform:/... Resource URIs. Multi-EPackage EREsources are not a problem since GenModel flattens them.)
| --- | --- | | Bugzilla Link | 576288 | | Status | NEW | | Importance | P3 normal | | Reported | Sep 27, 2021 11:25 EDT | | Modified | Sep 29, 2021 13:02 EDT | | See also | 487217 | | Reporter | Ed Willink |
Description
/org.eclipse.qvtd.pivot.qvtimperative/model/QVTimperative.ecore uses
eType="ecore:EClass ../../org.eclipse.qvtd.pivot.qvtbase/model/QVTbase.ecore#T-qvtbase-TypedModel">
The latter is necessary to support opening with the Sample Ecore Model Editor.
The former is an inconsistent design choice requiring mappings to unify.