eclipse-ocl / org.eclipse.ocl

Eclipse Public License 2.0
0 stars 0 forks source link

[pivot] Inconsistent import reference #2201

Open eclipse-ocl-bot opened 1 month ago

eclipse-ocl-bot commented 1 month ago

| --- | --- | | 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.

eclipse-ocl-bot commented 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.

eclipse-ocl-bot commented 1 month ago

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.)