eclipse-ocl-bot
commented
1 month ago By Ed Willink on Mar 28, 2018 10:56
LazyXMIidAssigningResourceImpl introduced as the XMIResourceImpl for all Pivot-based *.ecore metamodels.
Specifying a variable XXXPackImpl base class is undesirable. @extends works but I recall problems with @implements. Inserting a one line XXXPackageImpl.createResource redirect to LazyXMIidAssigningResourceImpl.createResource works fine, but...
createResource precedes various createYYYAnnotations that use an attachedHelper and so trigger the lazy xmi:id generation.
EPackageImpl.freeze() is behind protected API so testing for the EPackage.Registry registration seems the only way to detect end of XXXPackageImpl init.
Pushed to master for M7.
| --- | --- | | Bugzilla Link | 532947 | | Status | RESOLVED FIXED | | Importance | P3 normal | | Reported | Mar 27, 2018 06:35 EDT | | Modified | Mar 28, 2018 10:56 EDT | | Reporter | Ed Willink |
Description
Importing the org.eclipse.qvtd.pivot.qvtimperative project into an Eclipse workspace without a corresponding qvtbase project gives problems when QVTimperative.ocl is validated.
QVTimperative.ecore references qvtb superclassses by ../../etc but imports http://www.eclipse.org/qvt/2015/QVTbase - inelegant bit not necessarily wrong. The DelegatedSinglePackageResource seems to fix it up.
But a serious problem occurs resolving e.g. eSuperTypes="../../org.eclipse.qvtd.pivot.qvtbase/model/QVTbase.ecore#T-qvtbase-TypedModel" since the auto-generated xmi:id is not present in the Java variant of the model.
Options:
a) Add an XXXImpl customization to assignIds eagerly. An unpleasant overhead sincde they are mostly not needed.
b) Add an XXXImpl customization to create a variant XMIResource with a lazy getEObjectById overload.
c) Lazily assignIDs on the known call path from DelegatedSinglePackageResource.getEObject. Ugh! just waiting for more bugs ffrom more call-paths.
b) seems a winner