Community
Participate
Working Groups
When developing a non-trivial modeler, a common setup is to have the metamodels, Java code and VSM in a host Eclipse, and to test the result in a separate Eclipse runtime. If the runtime is launched in debug mode, the JVM is able to reload new versions of Java code as it is changed in the host workspace, but any change in the VSM requires a full restart of the runtime to see the results. It would be nice to support "hot VSM replace" to streamline the specifier's workflow. From what I can see, Java "hot code replace" relies on special communication channels (using the debug APIs) between the host JDT and the runtime's JVM, so we probably can not get the exact same specifier experience. Given that in this mode the actual VSMs are not really inside packaged JARs but in "pseudo-plugins" actually backed by plain files in the host's workspace, it seems it may be possible to support such a feature, but some experimentation is needed before we can be sure.
Moving to 6.0 at least to continue the experimentation. We may not be able to provide a completely transparent feature, but even with some limitations it could significantly improve some workflows for specifiers (and reduce frustrations).
scenarios to be handled scenario 1: 1- create, in host workspace, a VSP with a testDiagDesc diagram description that contains some mapping 2- launch a runtime and create a modeling project and a diagram with testDiagDesc 3- change the VSM so that changes are visible on diagram 4- click on "reload VP" action (TBD) -> the diagram should have been updated according to VSM changes scenario2: 1- create, in host workspace, a VSP with a testDiagDesc diagram description that contains some mapping 2- launch a runtime 3- import VSP in runtime workspace 4- create a modeling project and a diagram_VPPlugin with testDiagDesc from plugin and diagram_VPWorkspace with testDiagDesc from workspace 5- change the VSM so that changes are visible on diagram 6- click on "reload VP" action (TBD) -> the diagram should have been updated according to VSM changes scenario 3: 1-2- same as scenario1 3- delete the VSM 4- click on "reload VP" action (TBD) -> the diagram should have been closed and the viewpoint deactivated
The "Reload VSM From plug-ins" button should be accessible only for specifiers. It should be accessible globally that is not specific to a particular editor and not contextual to an object. I propose to add this button in a toolbar in eclipse main toolbar area. This toolbar could be available only with Viewpoint perspective. TBD
New Gerrit change created: https://git.eclipse.org/r/114976
Validation: The scenario VSM-0003-F has been added in manual test files and can be used for validation. It covers scneario1 and scenario2
Gerrit change https://git.eclipse.org/r/114976 was merged to [master]. Commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=734ac9d4e8c775f0ad7aeae0f6712059050a693a
It looks like there is an issue with the toolbar icon's visibility: it should only be visible when inside an Eclipse runtime (launched from a host), but it is also visible when starting a plain product (in the case, OD CE).
New Gerrit change created: https://git.eclipse.org/r/120705
Gerrit change https://git.eclipse.org/r/120705 was merged to [master]. Commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=2c7a849167a1ec0d33bb988b009acb10b33372ea
The issue described in Comment7 occurred when the oes.editor plug-in was not loaded yet which is the case at eclipse start if no sirius editor was in memento. It is now fixed with last commit.
scenario 3: 1-2- same as scenario1 3- delete the VSM 4- click on "reload VP" action (TBD) -> the diagram should have been closed and the viewpoint deactivated do not work! The viewpoint is deactivated but the representation is still open. If in the first workspace you made CTRL + Z to restore the VSM, in the second workspace, the "reload VP" action creates a read-only transaction rolled back exception. If you try to activate the viewpoint, an exception occurs: java.lang.NullPointerException at org.eclipse.sirius.business.api.helper.SiriusResourceHelper.getCorrespondingViewpoint(SiriusResourceHelper.java:161) at org.eclipse.sirius.business.api.session.ViewpointSelector.selectViewpoint(ViewpointSelector.java:65) at org.eclipse.sirius.ui.business.api.viewpoint.ViewpointSelectionCallback.selectViewpoint(ViewpointSelectionCallback.java:40) at org.eclipse.sirius.ui.business.api.viewpoint.ViewpointSelection$Callback.selectViewpoint(ViewpointSelection.java:490) at org.eclipse.sirius.ui.business.internal.commands.ChangeViewpointSelectionCommand.doExecute(ChangeViewpointSelectionCommand.java:111) at org.eclipse.emf.transaction.RecordingCommand.execute(RecordingCommand.java:135) at org.eclipse.emf.workspace.EMFCommandOperation.doExecute(EMFCommandOperation.java:119) at org.eclipse.emf.workspace.AbstractEMFOperation.execute(AbstractEMFOperation.java:150) at org.eclipse.core.commands.operations.DefaultOperationHistory.execute(DefaultOperationHistory.java:488) at org.eclipse.emf.workspace.impl.WorkspaceCommandStackImpl.doExecute(WorkspaceCommandStackImpl.java:208) at org.eclipse.emf.transaction.impl.AbstractTransactionalCommandStack.execute(AbstractTransactionalCommandStack.java:165) at org.eclipse.emf.transaction.impl.AbstractTransactionalCommandStack.execute(AbstractTransactionalCommandStack.java:219) at org.eclipse.sirius.ui.tools.internal.viewpoint.ViewpointHelper$1.run(ViewpointHelper.java:291) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:119)
New Gerrit change created: https://git.eclipse.org/r/123537
Gerrit change https://git.eclipse.org/r/123537 was merged to [master]. Commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=ab7a5e6e37fc72bfd06dc47515c106114051fa00
scenario 3 is put out of the scope of this ticket. This is now documented as a limitation.
Available in Sirius 6.0.0, see https://wiki.eclipse.org/Sirius/6.0.0 for details
