| First steps to Edapt with multiple ecore models [message #1804210] |
Wed, 20 March 2019 14:16  |
 Dimo Petroff
Messages: 7
Registered: November 2018 |
Junior Member |
|
|
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 #1804323 is a reply to message #1804210] |
Fri, 22 March 2019 12:32  |
|
Hi
when you create a history for a specific ecore file, Edapt will try to track the changes for the common one as well. Usually you don't want to repeat all the changes made in common in the history for each specfic ecore. So the way to go would be to have one big history for the common.ecore also referencing the specific ones. After creating the history when you right-click in the ecore editor for the common ecore, select "Load Resource..", and pick a specific ecore, the Edapt tooling will ask you whether you want to add this ecore to the history. You can repreat this for all specfic ecores in order to end up with one complete history tracking all changes.
This would be the easiest way.
For the EMF Forms project we can't ensure that all specific models will be installed by clients. Here we created a history per ecore (not tracking common changes in specific history) and then merge those histories into one during runtime using EMF APIs. (The Edapt history model is modeled in EMF as well) So this is a special case.
Regarding the editor:
The edapt tooling listens for when an Ecore Editor launches. It then uses the annotations added to the ecore model when the history was created to load the history file alongside the ecore. So using the ecore editor should work. Did you revert the annotation changes by any chance?
Cheers
Johannes
Johannes Faltermeier
Get professional Eclipse developer support:
http://eclipsesource.com/en/services/developer-support/
|
|
|
| Re: First steps to Edapt with multiple ecore models [message #1804880 is a reply to message #1804323] |
Tue, 02 April 2019 16:29 |
Dimo Petroff
Messages: 7
Registered: November 2018 |
Junior Member |
|
|
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 13:14 |
|
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
Johannes Faltermeier
Get professional Eclipse developer support:
http://eclipsesource.com/en/services/developer-support/
|
|
|
Powered by
FUDForum. Page generated in 0.01974 seconds
Search
Help
Register
Login
Home
