Community
Participate
Working Groups
This should become an EMF bug once a suitable simple repro is available. It occurs for the QVTd CS2AS Example1 and Example2 models. The over problem arises because // Initialize simple dependencies OCLstdlibPackage.eINSTANCE.eClass(); is missing. This happens when both TargetMM1.genmodel and EnvExample1.genmodel specify OCLstdlib as a usedGenPackage, and TargetMM1.genmodel specifies EnvExample1.genmodel as a further usedGenPackage. GenModel's categoraization of different levels of usage seems to fail and it thinks that the other OCLstdlibPackage user provides the init. The problem is 'cured' by removing the redundant TargetMM1.genmodel mention of OCLstdlib, so that we have a simple TargetMM1 uses EnvExample1 uses OCLstdlib daisy chain. However the problem reappears as soon as the TargetMM1.genmodel is reconciled and saved. The indirect usage is promoted to direct. So probably two problems. a) the missing OCLstdlibPackage.eINSTANCE.eClass() should appear, perhaps in both places if one has no domiance. b) the promotion of indirect to ditect by reconcile should not happen.
We can work around this in org.eclipse.ocl.examples.build.utilities.GenerateModel where the automatic reconcile and save occurs. The simple suppression of the indirect to direct promotion causes a generator failure. The promotion seems necessary. A slightly hacky suppression in the saved reconciled resource, but retention in the internal reconciled genmodel works.
(In reply to Ed Willink from comment #1) > A slightly hacky suppression in the saved reconciled resource, but retention > in the internal reconciled genmodel works. commit 38cfa6b3564c3df5cf2b1cc9809e1c71f13d1382 pushed to master for M3 Above fixes QVTd's tests. TODO extra QVTd example as an EMF repro.
