Community
Participate
Working Groups
When importing a set of packageUnits that contain packages that have dependencies across the packageUnit boundaries, the import encounters problems during the package import. The (first) problem seems to be that the packageLoader constructed in FlushHandler.handleModels calls EMFUtil.createEPackage with argument lookForResource == true. This causes a lookup of the resource in the resourceSet, which in turn delegates to the cdoPackageRegistry, which in turn calls *another* packageLoader (the repo), which in turn calls loadPackageUnit on the MEMStoreAccessor, which throws an UnsupportedOperationException. Apparent solution: use lookForResource = false. But this might cause the creation of Resource duds (resources that appear loaded, but are actually empty), because of the subsequent call to packageUnit.load(..) invokes ECoreUtil.resolveAll(*) on every ePackage obtained from the packageUnit. This also doesn't seem quite right to me. I think no resolution should be requested until all packageUnits have been processed...
Actually I've changed my mind: calling #createEPackage with lookForResource == true, makes sense. (In fact I can't think of a scenario when calling it with 'false' would make sense.) The problem is just that we have to keep the resourceSet from delegating to some other object, which may attempt a demandLoad or whatever. So, in the patch that I'll upload shortly, I'm introducing a derivative of ResourceSetImpl that allows the lookup delegation to be disabled/enabled as needed. Also, I'll add a boolean arg 'resolve' to the packageUnit.load(*) call, because I do still believe the resolution should be postponed until the resourceSet is known to contain the contents of ALL the packageUnits being imported.
Created attachment 185901 [details] Patch v1
Created attachment 185933 [details] Patch v2 - ready to be committed Reformatted slightly
Committed to HEAD
Available in R20110608-1407
