| First steps to Edapt with multiple ecore models [message #1804210] |
Wed, 20 March 2019 10:16  |
Eclipse User |
|
|
|
Hi,
I'm trying to get started with Edapt in a project where there is one common ecore and several others that reference it directly or through each other, in separate bundles.
I couldn't find any documentation or tutorials that address how to set up Edapt with multiple ecore models involved at all, and when I try ti wing it, it looks like the specific ecore models try to track the history of the common one (even adding an edapt annotation in the common.ecore with a history uri to the specific.history file), despite having already created a common.history (with a release representative of the initial state) for the common.ecore.
Now, I've had a look at the eclipsecon 2015 presenation and the emfforms projects where there are histories for multiple ecore models and no such annotations on the common ones, so I figure something is not quite right with my setup.
If anyone can give me some advice or point me to documentation or articles, or tutorials that can enlighten me, it would be much appreciated.
|
|
|
|
|
| Re: First steps to Edapt with multiple ecore models [message #1804880 is a reply to message #1804323] |
Tue, 02 April 2019 12:29  |
| Eclipse User |
|
|
|
Hi Johannes,
Keeping a common history file has worked well as a starting point, though I'm having issues with certain migrations. I run the migration like this:
if (needsMigration()) {
URI uri = getURI();
Migrator migrator = MigratorRegistry.getInstance().getMigrator(ReleaseUtils.getNamespaceURI(uri));
try {
List<EObject> migratedContents = migrator.migrateAndLoad(Collections.singletonList(uri), migrator.getRelease(getVersion()), null,
new NullProgressMonitor()).getResource(uri, false).getContents();
...
} catch (MigrationException e) {
...
}
...
}
It will fail and throw ClassCastExceptions if the model instance had references to elements from other models (which are tracked in the common history as well). After debugging for a while, it looks like somehow the eClass of the dynamic EObject is a different Java object instance that represents the same eClass of the resolved EObject, (they come from separate EPackage instances even), and because eClass.isInstance checks eClass identity with == rather than equality, it decides the eClasses are not compatible and it should throw the exception:
java.lang.ClassCastException: The value of type 'class com.name.space.here.argument.impl.ArgumentImpl' must be of type 'org.eclipse.emf.ecore.impl.EClassImpl@5d3a3383 (name: Argument) (instanceClassName: null) (abstract: false, interface: false)'
at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateSingleEObject.dynamicGet(EStructuralFeatureImpl.java:2604)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1027)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1011)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1003)
at org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImpl.hasNext(EContentsEList.java:439)
at org.eclipse.emf.ecore.util.EcoreUtil.resolveCrossReferences(EcoreUtil.java:306)
at org.eclipse.emf.ecore.util.EcoreUtil.resolveAll(EcoreUtil.java:300)
at org.eclipse.emf.ecore.util.EcoreUtil.resolveAll(EcoreUtil.java:285)
at org.eclipse.emf.edapt.internal.common.ResourceUtils.resolveAll(ResourceUtils.java:293)
at org.eclipse.emf.edapt.internal.common.ResourceUtils.loadResourceSet(ResourceUtils.java:149)
at org.eclipse.emf.edapt.internal.migration.internal.Persistency.loadModel(Persistency.java:110)
at org.eclipse.emf.edapt.internal.migration.execution.internal.MigrationReconstructor.loadRepository(MigrationReconstructor.java:189)
at org.eclipse.emf.edapt.internal.migration.execution.internal.MigrationReconstructor.endRelease(MigrationReconstructor.java:159)
at org.eclipse.emf.edapt.history.reconstruction.CompositeReconstructorBase.endRelease(CompositeReconstructorBase.java:179)
at org.eclipse.emf.edapt.history.reconstruction.ForwardReconstructorBase.doReconstruct(ForwardReconstructorBase.java:81)
at org.eclipse.emf.edapt.history.reconstruction.ForwardReconstructorBase.doReconstruct(ForwardReconstructorBase.java:57)
at org.eclipse.emf.edapt.history.reconstruction.CompositeReconstructorBase.reconstruct(CompositeReconstructorBase.java:74)
at org.eclipse.emf.edapt.migration.execution.Migrator.migrate(Migrator.java:269)
at org.eclipse.emf.edapt.migration.execution.Migrator.migrateAndLoad(Migrator.java:221)
...
Note that Argument is a class in the Argument package in argument.ecore, which has superclasses from common.ecore, and the uri of the resource being migrated points to an instance of a model from a different specific.ecore that contains classes which subclass the ones in common.ecore and have cross-references to model elements from argument.ecore and other specfic ecore models. All of them are part of the common edapt history.
Any idea how to correct this?
|
|
|
| Re: First steps to Edapt with multiple ecore models [message #1805004 is a reply to message #1804880] |
Thu, 04 April 2019 09:14 |
| Eclipse User |
|
|
|
Hi,
this is hard to judge without being able to debug it.
But from the stacktrace and your description it seems that we get confused between the dynamic reconstructed version of the model and the actual models from the EPackage-Registry.
You could check your ecores/history-files for inconsitencies how the referenced ecores are addressed (i.e. workspace relative path vs. ns-uri):
<eStructuralFeatures xsi:type="ecore:EReference" name="foo" eType="ecore:EClass ../../plugin.name/model/foo.ecore#//MyClazz" containment="true"/>
vs
<eStructuralFeatures xsi:type="ecore:EReference" name="foo" eType="ecore:EClass http://plugin.name/foo#//MyClazz" containment="true"/>
This might be a reason for duplicates.
Besides that, is the model your are migrating split into different XMIs? Maybe one file was not migrated and now causes the hickup?
Hope this helps!
Johannes
|
|
|
Powered by
FUDForum. Page generated in 0.03739 seconds
Home