Eclipse Community Forums: EMF "Technology" (Ecore Tools, EMFatic, etc) » [Edapt] Problem when migrating models that reference UML

Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » [Edapt] Problem when migrating models that reference UML

[Edapt] Problem when migrating models that reference UML [message #1724723]

Thu, 25 February 2016 10:23

Eclipse User

Hi,
I have a problem when trying to migrate a model that itself references Sysml profiles.

platform:/plugin/org.eclipse.papyrus.sysml14/model/SysML.profile.uml

During the migration I get a ClassCastException:

java.lang.ClassCastException: The value of type 'class org.eclipse.emf.ecore.impl.EClassImpl' must be of type 'org.eclipse.emf.ecore.impl.EClassImpl@16af0251 (name: EClassifier) (instanceClassName: null) (abstract: true, 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:304)
	at org.eclipse.emf.ecore.util.EcoreUtil.resolveAll(EcoreUtil.java:298)
	at org.eclipse.emf.ecore.util.EcoreUtil.resolveAll(EcoreUtil.java:283)
	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:106)
	at org.eclipse.emf.edapt.internal.migration.execution.internal.MigrationReconstructor.loadRepository(MigrationReconstructor.java:185)
	at org.eclipse.emf.edapt.internal.migration.execution.internal.MigrationReconstructor.endRelease(MigrationReconstructor.java:155)
	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:265)
	at org.eclipse.emf.edapt.migration.execution.Migrator.migrateAndLoad(Migrator.java:217)

Note that the SYSML Profile itself ist not part of the edapt history.

For short: does anyone has experiences with this kind of problem? Is it possible or is it known to be not possible to reference SYSML Model?

For those who are interesed in details:

I have spend hous investingating this issue but I am a little stuck.

I have an odd feeling because of this: In Persistency.loadMetamodel, the metamodelResource rootpackages are extended by all packages which have been loaded into the resourceSet.
One finds a package for:

http://www.eclipse.org/uml2/5.0.0/UML

The package is of type EPackage although I would expect it to be of type UMLPackage. This package is later on registered with the packageRegistry of the resourceSet into which the historic model is loaded. This happens in

ResourceUtils.loadResourceSet()

When a package for the above uri is later on requested, the EPackage is returned because it is directly contained in the package registry due to the registration in ResourceUtils. If it wouldn't be there, the request would be delegated to the delegate registry of the ResourceRegistry which is the global PackageRegistry and which would return an UMLPackage.

Any hints or help would be very much appreciated.

Regards
Thorsten

Re: [Edapt] Problem when migrating models that reference UML [message #1724749 is a reply to message #1724723]

Thu, 25 February 2016 12:18

Eclipse User

Removing those EPackages does not solve the problem. It seems to me that they have to be dynamic in order to fit to the other dynamic packages which are part of the history.

I stepped a little further and reached the point where the XMLHandler tries to resolve a package for the uri which contains the Ecore model for UML:

XMLHandler.getPackageForURI()

Calling this for the URI that points to the Ecore-UML Model

http://www.eclipse.org/uml2/schemas/Ecore/5
pathmap://UML_PROFILES/Ecore.profile.uml#_z1OFcHjqEdy8S4Cr8Rc_NA

results in the creation of DynamicEObjects. At the end of the getpackageForURI method a package is tried to be resolved from the loaded resource. In my case the content which is resolved is a DynamicEObject with the EClass EPackage

org.eclipse.emf.ecore.impl.DynamicEObjectImpl@6e2ab1f4 (eClass: org.eclipse.emf.ecore.impl.EClassImpl@3e6f3ad5 (name: EPackage) (instanceClassName: null) (abstract: false, interface: false))

This DynamicEObject only represents an EPackage but is not by itself an instanceof EPackage which is the reason why an EPackage for the URI cannot be resolved. As a result the package is demand resolved by the ExtendedMetaData (BasicExtendedMetaData.demandPackage) and in the following all required classes are also demand resolved (BasicExtendedMetaData.demandType). Finally all objects which are created on basis of this classes are of type AnyType.

With this insight, is there anybody out there who can help to find a solution? The problem is that we are already using edapt for migration of Version 2.2 of our model to Version 3.0 In Version 2.2 we have no such references as described above. Now we have introduced references to Sysml Profiles in V 3.0 and it is not possible to migrate from V 3.0 to V 3.1 anymore because now the historical models may contain refrences to the above types.

Again. Any help is appreciated.

Regards,
Thorsten

Re: [Edapt] Problem when migrating models that reference UML [message #1724757 is a reply to message #1724749]

Thu, 25 February 2016 13:03

Eclipse User

Hi

Welcome to the world of metamodel schizophrenia.

Unless you have a suitable URI normalizer, all references to the same
logical metamodel must use a VERY compatible URI.

i.e. do not use both ...Ecore.ecore and
http://www.eclipse.org/emf/2002/Ecore

For the most part using dynamic EObjects is a symptom that you have
already gone wrong and messed up accesses. Dynamic EObjects are however
required for profiles that have not been genmodelled.

To get some insight you can instrument every ResourceImpl creation to
observe the 'duplicates'.

If you cannot ensure that your technology avoids mismatching accesses
you need a normalizer. EcorePlugin's facilities can help normalize many
accesses. OCL's StandaloneProjectMap can do more.

Regards

Ed Willink

On 25/02/2016 17:18, Thorsten Schlathölter wrote:
> Removing those EPackages does not solve the problem. It seems to me
> that they have to be dynamic in order to fit to the other dynamic
> packages which are part of the history.
>
> I stepped a little further and reached the point where the XMLHandler
> tries to resolve a package for the uri which contains the Ecore model
> for UML:
>
>
> XMLHandler.getPackageForURI()
>
>
> Calling this for the URI that points to the Ecore-UML Model
>
> http://www.eclipse.org/uml2/schemas/Ecore/5
> pathmap://UML_PROFILES/Ecore.profile.uml#_z1OFcHjqEdy8S4Cr8Rc_NA
>
>
> results in the creation of DynamicEObjects. At the end of the
> getpackageForURI method a package is tried to be resolved from the
> loaded resource. In my case the content which is resolved is a
> DynamicEObject with the EClass EPackage
>
>
> org.eclipse.emf.ecore.impl.DynamicEObjectImpl@6e2ab1f4 (eClass:
> org.eclipse.emf.ecore.impl.EClassImpl@3e6f3ad5 (name: EPackage)
> (instanceClassName: null) (abstract: false, interface: false))
>
>
> This DynamicEObject only represents an EPackage but is not by itself
> an instanceof EPackage which is the reason why an EPackage for the URI
> cannot be resolved. As a result the package is demand resolved by the
> ExtendedMetaData (BasicExtendedMetaData.demandPackage) and in the
> following all required classes are also demand resolved
> (BasicExtendedMetaData.demandType). Finally all objects which are
> created on basis of this classes are of type AnyType.
>
> With this insight, is there anybody out there who can help to find a
> solution? The problem is that we are already using edapt for migration
> of Version 2.2 of our model to Version 3.0 In Version 2.2 we have no
> such references as described above. Now we have introduced references
> to Sysml Profiles in V 3.0 and it is not possible to migrate from V
> 3.0 to V 3.1 anymore because now the historical models may contain
> refrences to the above types.
>
> Again. Any help is appreciated.
>
> Regards,
> Thorsten
>

Re: [Edapt] Problem when migrating models that reference UML [message #1724761 is a reply to message #1724757]

Thu, 25 February 2016 13:51

Eclipse User

Hi Ed,
thanks for sharing this. But I am not sure if your post really touches the problem. Edapt uses DynamicEObjects to transform a model into an older revision of the model. Therefore DynamicEObjects are expected to show up. The problems is that we have a profile that itself is under version control of Edapt and that uses Ecore Types. The UML Ecore Model that provides the types is itself not under version control. Nevertheless it gets transformed with the above side effects. We had a similar issue with ReqIf because it uses it's own types. We solved it by registering a factory. I wonder if this could help here as well...

Anyway thanks for the response.

Regards,
Thorsten

Re: [Edapt] Problem when migrating models that reference UML [message #1724771 is a reply to message #1724761]

Thu, 25 February 2016 15:59

Eclipse User

Hi

A ResourceFactory perghaps. An EFasctory probbaly not.

It seems you probably have two genuinely different 'same'-URIed
resources. You might find two ResourceSets helps, perhaps with a third
for shared resources registered in the URIResourceMap of the other
ResourceSets.

NB. Some tooling appropriates the eResource().getResourceSet() of
genmodelled EPackages to point at the most recent ResourceSet making
proxy resolution a bit less unpredictable.

Regards

Ed Willink

On 25/02/2016 18:51, Thorsten Schlathölter wrote:
> Hi Ed,
> thanks for sharing this. But I am not sure if your post really touches
> the problem. Edapt uses DynamicEObjects to transform a model into an
> older revision of the model. Therefore DynamicEObjects are expected to
> show up. The problems is that we have a profile that itself is under
> version control of Edapt and that uses Ecore Types. The UML Ecore
> Model that provides the types is itself not under version control.
> Nevertheless it gets transformed with the above side effects. We had
> a similar issue with ReqIf because it uses it's own types. We solved
> it by registering a factory. I wonder if this could help here as well...
>
> Anyway thanks for the response.
> Regards,
> Thorsten

Re: [Edapt] Problem when migrating models that reference UML [message #1724855 is a reply to message #1724771]

Fri, 26 February 2016 09:48

Eclipse User

Hi,

Have you tried if a migration is possible when you add all ecores that are required in your model to the history?
Would it be possible for you to provide a small example which demonstrates the problem? I am not familiar with the UML/SysML models, so it's hard to get what is going wrong.

Regards
Johannes

Re: [Edapt] Problem when migrating models that reference UML [message #1724985 is a reply to message #1724855]

Sun, 28 February 2016 10:59

Eclipse User

Hi,
I loaded all ecore files that are used in my model into the history.
I still get a ClassCast Exception:

java.lang.ClassCastException: The value of type 'class org.eclipse.emf.ecore.impl.DynamicEObjectImpl' must be of type 'org.eclipse.emf.ecore.impl.EClassImpl@35d0499b (name: Model) (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:304)
	at org.eclipse.emf.ecore.util.EcoreUtil.resolveAll(EcoreUtil.java:294)
	at org.eclipse.emf.ecore.util.EcoreUtil.resolveAll(EcoreUtil.java:283)
	at org.eclipse.emf.edapt.internal.common.ResourceUtils.resolveAll(ResourceUtils.java:297)
	at org.eclipse.emf.edapt.internal.common.ResourceUtils.loadResourceSet(ResourceUtils.java:149)
	at org.eclipse.emf.edapt.internal.migration.internal.Persistency.loadModel(Persistency.java:106)
	at org.eclipse.emf.edapt.internal.migration.execution.internal.MigrationReconstructor.loadRepository(MigrationReconstructor.java:185)
	at org.eclipse.emf.edapt.internal.migration.execution.internal.MigrationReconstructor.endRelease(MigrationReconstructor.java:155)
	at org.eclipse.emf.edapt.history.reconstruction.CompositeReconstructorBase.endRelease(CompositeReconstructorBase.java:179)

The ClassCast is thrown here:

if (!eClass.isInstance(resolvedEObject))
            {
              throw new ClassCastException("The value of type '" + resolvedEObject.getClass() + "' must be of type '" + eClass + "'");
            }

eClass is a Model (org.eclipse.uml2.uml.Model). The resolvedEObject is a DynamicEObject with an eClass which also represents a Model (org.eclipse.uml2.uml.Model) but is loaded in a different package.

If I check MetamodelUtils.createIndependentMetamodelCopy I see that some packages are registered twice. The UML package is one one them.
Registration happens here:

Thread [main] (Suspended (breakpoint at line 163 in ResourceUtils))	
	ResourceUtils.register(List<EPackage>, Registry) line: 163	
	ResourceUtils.loadResourceSet(List<URI>, List<EPackage>, IResourceSetFactory) line: 121	
	Persistency.loadModel(List<URI>, Metamodel, IResourceSetFactory) line: 106	
	MigrationReconstructor.loadRepository() line: 185	
	MigrationReconstructor.endRelease(Release) line: 155	
	EcoreForwardReconstructor(CompositeReconstructorBase).endRelease(Release) line: 179	
	EcoreForwardReconstructor(ForwardReconstructorBase).doReconstruct(Release) line: 81	
	EcoreForwardReconstructor(ForwardReconstructorBase).doReconstruct(EObject, History, boolean) line: 57	
	EcoreForwardReconstructor(CompositeReconstructorBase).reconstruct(Release, boolean) line: 74	
	Migrator.migrate(List<URI>, Release, Release, IProgressMonitor) line: 265	
	Migrator.migrateAndLoad(List<URI>, Release, Release, IProgressMonitor) line: 217

I think the first time is a registration from loading the history model. Second time comes from resolving the references between the root packages.

Any idea about this?

Thanks in advance.
Thorsten

Re: [Edapt] Problem when migrating models that reference UML [message #1724989 is a reply to message #1724985]

Sun, 28 February 2016 12:43

Eclipse User

Hi

Classic metamodel schizophrenia.

Do not load the 'same' model twice. Either correct ALL references to use
the same document URI spelling, or use an EPackageRegistry that
merges/re-uses models with same package URIs.

Regards

ed Willink

On 28/02/2016 15:59, Thorsten Schlathölter wrote:
> Hi,
> I loaded all ecore files that are used in my model into the history. I
> still get a ClassCast Exception:
>
>
> java.lang.ClassCastException: The value of type 'class
> org.eclipse.emf.ecore.impl.DynamicEObjectImpl' must be of type
> 'org.eclipse.emf.ecore.impl.EClassImpl@35d0499b (name: Model)
> (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:304)
> at
> org.eclipse.emf.ecore.util.EcoreUtil.resolveAll(EcoreUtil.java:294)
> at
> org.eclipse.emf.ecore.util.EcoreUtil.resolveAll(EcoreUtil.java:283)
> at
> org.eclipse.emf.edapt.internal.common.ResourceUtils.resolveAll(ResourceUtils.java:297)
> at
> org.eclipse.emf.edapt.internal.common.ResourceUtils.loadResourceSet(ResourceUtils.java:149)
> at
> org.eclipse.emf.edapt.internal.migration.internal.Persistency.loadModel(Persistency.java:106)
> at
> org.eclipse.emf.edapt.internal.migration.execution.internal.MigrationReconstructor.loadRepository(MigrationReconstructor.java:185)
> at
> org.eclipse.emf.edapt.internal.migration.execution.internal.MigrationReconstructor.endRelease(MigrationReconstructor.java:155)
> at
> org.eclipse.emf.edapt.history.reconstruction.CompositeReconstructorBase.endRelease(CompositeReconstructorBase.java:179)
>
>
> The ClassCast is thrown here:
>
>
> if (!eClass.isInstance(resolvedEObject))
> {
> throw new ClassCastException("The value of type '" +
> resolvedEObject.getClass() + "' must be of type '" + eClass + "'");
> }
>
>
> eClass is a Model (org.eclipse.uml2.uml.Model). The resolvedEObject is
> a DynamicEObject with an eClass which also represents a Model
> (org.eclipse.uml2.uml.Model) but is loaded in a different package.
>
> If I check MetamodelUtils.createIndependentMetamodelCopy I see that
> some packages are registered twice. The UML package is one one them.
> Registration happens here:
>
>
> Thread [main] (Suspended (breakpoint at line 163 in ResourceUtils))
> ResourceUtils.register(List<EPackage>, Registry) line: 163
> ResourceUtils.loadResourceSet(List<URI>, List<EPackage>,
> IResourceSetFactory) line: 121
> Persistency.loadModel(List<URI>, Metamodel, IResourceSetFactory)
> line: 106
> MigrationReconstructor.loadRepository() line: 185
> MigrationReconstructor.endRelease(Release) line: 155
> EcoreForwardReconstructor(CompositeReconstructorBase).endRelease(Release)
> line: 179
> EcoreForwardReconstructor(ForwardReconstructorBase).doReconstruct(Release)
> line: 81
> EcoreForwardReconstructor(ForwardReconstructorBase).doReconstruct(EObject,
> History, boolean) line: 57
> EcoreForwardReconstructor(CompositeReconstructorBase).reconstruct(Release,
> boolean) line: 74
> Migrator.migrate(List<URI>, Release, Release, IProgressMonitor)
> line: 265
> Migrator.migrateAndLoad(List<URI>, Release, Release,
> IProgressMonitor) line: 217
>
>
> I think the first time is a registration from loading the history
> model. Second time comes from resolving the references between the
> root packages.
>
> Any idea about this?
>
> Thanks in advance.
> Thorsten
>

Re: [Edapt] Problem when migrating models that reference UML [message #1725075 is a reply to message #1724989]

Mon, 29 February 2016 09:42

Eclipse User

Hi Johannes,
I have created a SampleProject that tries to load in the UML model.
MyEcoreTest fails with an ArrayStoreException.

java.lang.ArrayStoreException: org.eclipse.emf.ecore.impl.EObjectImpl
	at org.eclipse.emf.common.util.BasicEList.assign(BasicEList.java:118)
	at org.eclipse.emf.common.util.BasicEList.addUnique(BasicEList.java:417)
	at org.eclipse.emf.common.notify.impl.NotifyingListImpl.doAddUnique(NotifyingListImpl.java:325)
	at org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUnique(NotifyingListImpl.java:309)
	at org.eclipse.emf.common.util.AbstractEList.add(AbstractEList.java:303)
	at org.eclipse.emf.edapt.history.reconstruction.EcoreReconstructorSwitchBase.add(EcoreReconstructorSwitchBase.java:51)
	at org.eclipse.emf.edapt.history.reconstruction.EcoreReconstructorSwitchBase.create(EcoreReconstructorSwitchBase.java:95)
	at org.eclipse.emf.edapt.history.reconstruction.EcoreForwardReconstructor$EcoreReconstructorSwitch.caseCreate(EcoreForwardReconstructor.java:120)
	at org.eclipse.emf.edapt.spi.history.util.HistorySwitch.doSwitch(HistorySwitch.java:218)
	at org.eclipse.emf.edapt.spi.history.util.HistorySwitch.doSwitch(HistorySwitch.java:104)
	at org.eclipse.emf.edapt.spi.history.util.HistorySwitch.doSwitch(HistorySwitch.java:90)
	at org.eclipse.emf.edapt.history.reconstruction.EcoreForwardReconstructor.startChange(EcoreForwardReconstructor.java:71)
	at org.eclipse.emf.edapt.history.reconstruction.ForwardReconstructorBase.doReconstruct(ForwardReconstructorBase.java:97)
	at org.eclipse.emf.edapt.history.reconstruction.ForwardReconstructorBase.doReconstruct(ForwardReconstructorBase.java:102)
	at org.eclipse.emf.edapt.history.reconstruction.ForwardReconstructorBase.doReconstruct(ForwardReconstructorBase.java:78)
	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:265)
	at org.eclipse.emf.edapt.migration.execution.Migrator.migrateAndLoad(Migrator.java:217)
	at my.MyEcoreTest.performMigration(MyEcoreTest.java:165)
	at my.MyEcoreTest.loadResource(MyEcoreTest.java:147)
	at my.MyEcoreTest.loadV1_0_Test(MyEcoreTest.java:124)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
	at org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(RemotePluginTestRunner.java:62)
	at org.eclipse.pde.internal.junit.runtime.CoreTestApplication.run(CoreTestApplication.java:23)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:587)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:198)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:669)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:608)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1515)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1488)

At this stage all I have done is to load the UML model into My.ecore model. Edapt then asks to add the new models to the history which I have agreed.
I then moved the new models (UML Model, UML Type Model, Ecore Model) to the first release.

I would expect other problems once an instance of UML model is used in My model but I am not shure if it makes sense to go further at this point in time. So I provide the SampleProject as is.

Regards,
Thorsten

Attachment: SampleProject.zip
(Size: 378.95KB, Downloaded 164 times)

Re: [Edapt] Problem when migrating models that reference UML [message #1725281 is a reply to message #1725075]

Wed, 02 March 2016 04:13

Eclipse User

Hi,

I took a look at your sample and I think that the UML.ecore is the problem at this stage.
As Ed pointed out all references to the same EPackage should use the same document URI spelling.
In the UML.ecore we have these two flavours:
<eClassifiers xsi:type="ecore:EClass" name="Element" abstract="true" eSuperTypes="platform:/plugin/org.eclipse.emf.ecore/model/Ecore.ecore#//EModelElement">
<eOperations name="maximum_one_parameter_node" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EBoolean">

When I did a search and replace to use http://www.eclipse.org/emf/2002/Ecore# consistently and recreated the history I did not get that ArrayStoreException.

Cheers
Johannes

Previous Topic:	[EEF] Preview EEF Version 2.0.0
Next Topic:	[Edapt] Loading Resource in a Release other than the first one fails

Goto Forum:

-=] Back to Top [=-

Current Time: Sun Jul 06 13:20:16 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter