Eclipse Community Forums: EMF "Technology" (Ecore Tools, EMFatic, etc) » [EMF Forms] Viewmodel migration to 1.9.0 fails

Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » [EMF Forms] Viewmodel migration to 1.9.0 fails(Conversion from 1.5.1 to 1.9.0 fails with " The input resource does not contain a valid VView.")

Show: Today's Messages :: Show Polls :: Message Navigator

[EMF Forms] Viewmodel migration to 1.9.0 fails [message #1735529]

Mon, 20 June 2016 17:50

Charles Eutsler

Messages: 19
Registered: July 2009

Junior Member

We are trying to upgrade from EMF-ECP 1.5.1 to the latest release candidate of version 1.9.0. We have two sets of view models. One set went through the conversion with no problems. All the view models in the other set result in the exception "org.eclipse.ui.PartInitException: The input resource does not contain a valid VView. Please check your file."

A difference between the two sets of view models is the ecore models they're based on. The ecore model for the set of view models that did convert is in a single model file. The set of view models that does not convert is based on models that have a common base model defined in one ecore file and are extended in their own ecore models.

I have recreated one of the view models with version 1.9.0 by hand and defined it with the same elements as the model that was created with version 1.5.1. The two appear identical except for the addition of "/170" in the xmlns:org.eclipse.emf.ecp.view.model value and the addition of the xmi:id to all of the elements.

Does the automatic conversion deal with view models whose ecore models extend other ecore models?

Report message to a moderator

Re: [EMF Forms] Viewmodel migration to 1.9.0 fails [message #1735608 is a reply to message #1735529]

Tue, 21 June 2016 12:25

Johannes Faltermeier

Messages: 96
Registered: December 2013

Member

Hi Charles,

actually the migration should work in both described cases.
Could you share the full stacktrace/earlier log messages and/or a minimal example?
Is there something special with your views/setup/ecores? E.g. are the rootEClass / ecorePath attributes set in the view models that fail migration? Are the ecores also installed in the IDE? Are all ecores valid at the moment?

Regards
Johannes

Johannes Faltermeier

Get professional Eclipse developer support:
http://eclipsesource.com/en/services/developer-support/

Report message to a moderator

Re: [EMF Forms] Viewmodel migration to 1.9.0 fails [message #1735683 is a reply to message #1735608]

Tue, 21 June 2016 23:40

Charles Eutsler

Messages: 19
Registered: July 2009

Junior Member

As far as I can tell, the view models have the rootEClass and ecorePath attributes set. And the ecores are in in a project in the workspace (if that is what you're asking about being installed in the IDE). And they are all valid.

Below is the stack trace from the View Model Editor after I say Yes to the "Do you want to migrate it to the latest version?"

Attached are two ecore models that are referenced by the attached view model. Any pointers to getting these migrated will be very much appreciated.

--Charles Eutsler

org.eclipse.ui.PartInitException: The input resource does not contain a valid VView. Please check your file.
at org.eclipse.emf.ecp.ide.editor.view.ViewEditorPart.loadView(ViewEditorPart.java:227)
at org.eclipse.emf.ecp.ide.editor.view.ViewEditorPart.init(ViewEditorPart.java:152)
at org.eclipse.ui.internal.EditorReference.initialize(EditorReference.java:390)
at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.create(CompatibilityPart.java:305)
at sun.reflect.GeneratedMethodAccessor68.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:55)
at org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:888)
at org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:869)
at org.eclipse.e4.core.internal.di.InjectorImpl.inject(InjectorImpl.java:120)
at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:337)
at org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:258)
at org.eclipse.e4.core.contexts.ContextInjectionFactory.make(ContextInjectionFactory.java:162)
at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.createFromBundle(ReflectionContributionFactory.java:104)
at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.doCreate(ReflectionContributionFactory.java:73)
at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.create(ReflectionContributionFactory.java:55)
at org.eclipse.e4.ui.workbench.renderers.swt.ContributedPartRenderer.createWidget(ContributedPartRenderer.java:127)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createWidget(PartRenderingEngine.java:983)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:662)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:766)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.access$2(PartRenderingEngine.java:737)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$7.run(PartRenderingEngine.java:731)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:715)
at org.eclipse.e4.ui.workbench.renderers.swt.StackRenderer.showTab(StackRenderer.java:1246)
at org.eclipse.e4.ui.workbench.renderers.swt.LazyStackRenderer$1.handleEvent(LazyStackRenderer.java:69)
at org.eclipse.e4.ui.services.internal.events.UIEventHandler$1.run(UIEventHandler.java:40)
at org.eclipse.swt.widgets.Synchronizer.syncExec(Synchronizer.java:187)
at org.eclipse.ui.internal.UISynchronizer.syncExec(UISynchronizer.java:156)
at org.eclipse.swt.widgets.Display.syncExec(Display.java:4734)
at org.eclipse.e4.ui.internal.workbench.swt.E4Application$1.syncExec(E4Application.java:218)
at org.eclipse.e4.ui.services.internal.events.UIEventHandler.handleEvent(UIEventHandler.java:36)
at org.eclipse.equinox.internal.event.EventHandlerWrapper.handleEvent(EventHandlerWrapper.java:197)
at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:197)
at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:1)
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
at org.eclipse.equinox.internal.event.EventAdminImpl.dispatchEvent(EventAdminImpl.java:135)
at org.eclipse.equinox.internal.event.EventAdminImpl.sendEvent(EventAdminImpl.java:78)
at org.eclipse.equinox.internal.event.EventComponent.sendEvent(EventComponent.java:39)
at org.eclipse.e4.ui.services.internal.events.EventBroker.send(EventBroker.java:81)
at org.eclipse.e4.ui.internal.workbench.UIEventPublisher.notifyChanged(UIEventPublisher.java:59)
at org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify(BasicNotifierImpl.java:374)
at org.eclipse.e4.ui.model.application.ui.impl.ElementContainerImpl.setSelectedElement(ElementContainerImpl.java:171)
at org.eclipse.e4.ui.internal.workbench.ModelServiceImpl.showElementInWindow(ModelServiceImpl.java:488)
at org.eclipse.e4.ui.internal.workbench.ModelServiceImpl.bringToTop(ModelServiceImpl.java:454)
at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.delegateBringToTop(PartServiceImpl.java:705)
at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.bringToTop(PartServiceImpl.java:392)
at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.showPart(PartServiceImpl.java:1145)
at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:3210)
at org.eclipse.ui.internal.WorkbenchPage.access$23(WorkbenchPage.java:3125)
at org.eclipse.ui.internal.WorkbenchPage$9.run(WorkbenchPage.java:3107)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:3102)
at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:3066)
at org.eclipse.ui.actions.OpenWithMenu.openEditor(OpenWithMenu.java:338)
at org.eclipse.ui.actions.OpenWithMenu$2.handleEvent(OpenWithMenu.java:180)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4353)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1061)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4172)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3761)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:115

Attachment: Authorization.ecore
(Size: 1.61KB, Downloaded 120 times)
Attachment: Teradatabase.ecore
(Size: 18.98KB, Downloaded 126 times)
Attachment: AuthorizationCreate.view
(Size: 2.12KB, Downloaded 147 times)

Report message to a moderator

Re: [EMF Forms] Viewmodel migration to 1.9.0 fails [message #1735716 is a reply to message #1735683]

Wed, 22 June 2016 08:36

Johannes Faltermeier

Messages: 96
Registered: December 2013

Member

Hi,
your ecores have references to the Ecore.ecore. But the serialized references are mixing "http://www.eclipse.org/emf/2002/Ecore#" and "../../org.eclipse.emf.ecore/model/Ecore.ecore#" to address it. So when you open both ecores in a text editor and replace "../../org.eclipse.emf.ecore/model/Ecore.ecore#" with "http://www.eclipse.org/emf/2002/Ecore#" in both files, then restart your IDE and try the migration again, it should work.
Cheers
Johannes

Johannes Faltermeier

Get professional Eclipse developer support:
http://eclipsesource.com/en/services/developer-support/

Report message to a moderator

Re: [EMF Forms] Viewmodel migration to 1.9.0 fails [message #1735817 is a reply to message #1735716]

Wed, 22 June 2016 23:54

Charles Eutsler

Messages: 19
Registered: July 2009

Junior Member

I made the changes to the ecore models and was able to do the migration of the view models. I was unable to answer "Yes" to the question of whether I wanted to migrate all the view models. When I tried that, I got the "The input resource does not contain a valid VView. Please check your file." message. I had to migrate them individually.

Thanks for the help.

We're migrating from 1.5.1 to the latest version to make use of the localization feature that was introduced in 1.6.0. I've tried following the instructions shown at How to customize EMF Forms and am not seeing that the properties are being used.

So far, I have tried only to externalize the names of some Leaf Categories of a Categorization. For instance, I gave the Name field the value "%General". In the plug-in's OSGI-INF/l10n/bundle.properties I added the entry:

General = GENERAL

When the form is rendered, the category appears as "%General". From what I understand, I don't need to add an Bundle-initialization entry in the MANIFEST.MF since that is the default location. (But I did try adding Bundle-initialization and Bundle-initialisation entries but resulted in no change.)

Am I missing something?

Report message to a moderator

Re: [EMF Forms] Viewmodel migration to 1.9.0 fails [message #1735928 is a reply to message #1735817]

Thu, 23 June 2016 16:45

Johannes Faltermeier

Messages: 96
Registered: December 2013

Member

Hi,

this might be because of missing dependencies. You can (temporarily) add the org.eclipse.emfforms.setup.base to your launch configuration, validate and add anything that is missing. This bundle has no functionality but lists the most common dependencies.
Does this solve the problem?

Cheers

Johannes Faltermeier

Get professional Eclipse developer support:
http://eclipsesource.com/en/services/developer-support/

Report message to a moderator

Re: [EMF Forms] Viewmodel migration to 1.9.0 fails [message #1735931 is a reply to message #1735928]

Thu, 23 June 2016 17:18

Charles Eutsler

Messages: 19
Registered: July 2009

Junior Member

I'm thinking now that it is because I haven't gotten our custom renderers refactored to play fully with the new framework. The LocalizationViewModelService.instantiate method is reached by way of the EMVFormsLegacyServiceFactory. There is no LocalizationAdapter among the VView's adapters. So I'm thinking that my problem will be solved once I figure out how our custom renderers need to be refactored.

Thanks.

Report message to a moderator

Re: [EMF Forms] Viewmodel migration to 1.9.0 fails [message #1735951 is a reply to message #1735931]

Fri, 24 June 2016 00:08

Charles Eutsler

Messages: 19
Registered: July 2009

Junior Member

After a bit more work, I am still not able to see view model elements being localized (such as the Name of a Leaf Category of a Categorization). I am pretty sure that I have removed all of our customizations (custom renderers and layout provider). I thought that maybe our customizations were interfering with the localization. But, when it gets to where a name is specified with a "%", the localizationAdapter is null. Below is the stack trace to the point where a "%"-prefixed word is supposed to be localized but the localizationAdapter is null. Does this give any clues?

Thanks for your attention.

--Charles Eutsler

Thread [main] (Suspended (breakpoint at line 136 in LocalizationViewModelService))
owns: RunnableLock (id=147)
LocalizationViewModelService.localize(LocalizationAdapter, VElement) line: 136
LocalizationViewModelService.checkContents(LocalizationAdapter, VElement) line: 124
LocalizationViewModelService.localizeView(LocalizationAdapter, VElement) line: 106
LocalizationViewModelService.instantiate(ViewModelContext) line: 83
EMFFormsLegacyLocalServiceFactory<T>(EMFFormsAbstractLegacyServiceFactory<T>).createService(EMFFormsViewContext) line: 96
EMFFormsLegacyLocalServiceFactory<T>(EMFFormsAbstractLegacyServiceFactory<T>).createService(EMFFormsViewContext) line: 1
EMFFormsViewServiceManagerImpl.getServiceOptional(Class<T>, Map<Class<?>,EMFFormsViewServiceFactory<?>>, EMFFormsViewContext) line: 100
EMFFormsViewServiceManagerImpl.createLocalImmediateService(Class<T>, EMFFormsViewContext) line: 112
ViewModelContextImpl.loadImmediateServices() line: 302
ViewModelContextImpl.instantiate() line: 266
ViewModelContextImpl.<init>(VElement, EObject) line: 164
ViewModelContextFactory.createViewModelContext(VElement, EObject) line: 42
ECPSWTViewRendererImpl.render(Composite, EObject, VView) line: 76
TablePropertyFormContributor.renderPropertyForm(Composite, Object, boolean, boolean) line: 52
TeradataTablePropertyForm(AdminPropertyForm).renderPropertyForm(Composite, IPropertyFormContributor) line: 442
TeradataTablePropertyForm(AdminPropertyForm).renderForm() line: 261
TeradataTablePropertyForm(AdminPropertyForm).createForm() line: 244
TeradataTablePropertyForm.<init>(String, String, IConnectionProfile, TeradataViewPartUtil$PropertyFormState, IPropertyFormContributor, NavigationContext, ObjectListView, CommonView) line: 97
OpenTeradataPropertyFormAction$1.run() line: 217
RunnableLock.run() line: 35
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 136
Display.runAsyncMessages(boolean) line: 4147
Display.readAndDispatch() line: 3764
PartRenderingEngine$9.run() line: 1151
Realm.runWithDefault(Realm, Runnable) line: 332
PartRenderingEngine.run(MApplicationElement, IEclipseContext) line: 1032
E4Workbench.createAndRunUI(MApplicationElement) line: 148
Workbench$5.run() line: 636
Realm.runWithDefault(Realm, Runnable) line: 332
Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 579
PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 150
IDEApplication.start(IApplicationContext) line: 135
EclipseAppHandle.run(Object) line: 196
EclipseAppLauncher.runApplication(Object) line: 134
EclipseAppLauncher.start(Object) line: 104
EclipseStarter.run(Object) line: 380
EclipseStarter.run(String[], Runnable) line: 235
NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]
NativeMethodAccessorImpl.invoke(Object, Object[]) line: not available
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: not available
Method.invoke(Object, Object...) line: not available
Main.invokeFramework(String[], URL[]) line: 648
Main.basicRun(String[]) line: 603
Main.run(String[]) line: 1465
Main.main(String[]) line: 1438

Report message to a moderator

Re: [EMF Forms] Viewmodel migration to 1.9.0 fails [message #1736062 is a reply to message #1735951]

Fri, 24 June 2016 18:48

Charles Eutsler

Messages: 19
Registered: July 2009

Junior Member

I figured out what I was missing in the localizing problem. I missed the sentence "If you provide a View Model by your own means (e.g. by implementing a ViewModelProvider), you can simply add a LocalizationAdapter to the View element manually." When I added the LocalizationAdapter in our ViewModelProvider, things work.

Thanks.

Report message to a moderator

Previous Topic:	using part of EMF model in Preferences
Next Topic:	Managing dependencies between EMF resources.

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Mon May 25 22:20:10 GMT 2020

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter