Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » [Edapt] Loading Resource in a Release other than the first one fails
[Edapt] Loading Resource in a Release other than the first one fails [message #1725069] Mon, 29 February 2016 14:22 Go to next message
Thorsten Schlathölter is currently offline Thorsten SchlathölterFriend
Messages: 296
Registered: February 2012
Location: Düsseldorf
Senior Member
Hi,
this seems to be the same issue as reported here:

https://www.eclipse.org/forums/index.php?t=msg&th=805271&goto=1415184&#msg_1415184

I came across this while trying to create a simple sample project that imports UML model with edapt.

I think this is still an issue. And I did not find a BugReport on it. The requested stack trace is as follows:

java.lang.NullPointerException
	at org.eclipse.emf.edapt.history.reconstruction.EcoreReconstructorSwitchBase.add(EcoreReconstructorSwitchBase.java:49)
	at org.eclipse.emf.edapt.history.reconstruction.EcoreReconstructorSwitchBase.create(EcoreReconstructorSwitchBase.java:95)
	at org.eclipse.emf.edapt.internal.migration.execution.internal.MigrationReconstructor$MigrationReconstructorSwitch.caseCreate(MigrationReconstructor.java:388)
	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.internal.migration.execution.internal.MigrationReconstructor.startChange(MigrationReconstructor.java:212)
	at org.eclipse.emf.edapt.history.reconstruction.CompositeReconstructorBase.startChange(CompositeReconstructorBase.java:146)
	at org.eclipse.emf.edapt.history.reconstruction.EcoreForwardReconstructor.startChange(EcoreForwardReconstructor.java:68)
	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:253)
	at my.MyEcoreTest.loadResource(MyEcoreTest.java:234)
	at my.MyEcoreTest.loadV1_0_Test(MyEcoreTest.java:211)
	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)


I add a simple eclipse project with two models, that reproduces the problem. If the add model changed is moved to the first release, everything works fine.


Regards,
Thorsten
Re: [Edapt] Loading Resource in a Release other than the first one fails [message #1725284 is a reply to message #1725069] Wed, 02 March 2016 09:22 Go to previous message
Johannes Faltermeier is currently offline Johannes FaltermeierFriend
Messages: 68
Registered: December 2013
Member
Hi,

thanks for the example. I opened a bugzilla: https://bugs.eclipse.org/bugs/show_bug.cgi?id=488828

Once the migration has reached the state where the source release, which was passed to the migrator, is fully reconstructed, the MigrationReconstructor is enabled. This is the point where not only the metamodel but also the model has to be loaded and migrated. This means that in order to load the outdated model we need to create the suitable metamodel at this point.

(This also means, that you don't have to move the composite change to the first release, but it has to be in a release before or in the source release.)

To solve this problem we need to create a mechanism to contribute new EPackages to (and not only change or update them) the created Metamodel after its initial creation.

Cheers
Johannes


Johannes Faltermeier

Get professional Eclipse developer support:
http://eclipsesource.com/en/services/developer-support/
Previous Topic:[Edapt] Problem when migrating models that reference UML
Next Topic:[ECP] Table Custom Control
Goto Forum:
  


Current Time: Thu Sep 21 01:42:48 GMT 2017

Powered by FUDForum. Page generated in 0.04654 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software