A couple of questions inline below.
Hi, Ernesto,
See some replies in-line, below.
HTH,
Christian
On 2 November, 2016 at 16:00:57, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:
I'm not on Oxygen. I recreated the dev environment to make sure I was on Neon.1. I have installed in my dev environment a few extras such as:
a) CDT
b) CMake Editor
c) Dynamic Languages Toolkit - ShellEd IDE
d) Ecore Diagram Editor (SDK)
There has been a history of incompatibility between the ECore Diagram Editor and GMF-based applications, in particular Papyrus. IIRC, older releases up to something like 2.0 were okay to combine with Papyrus but the latest releases, not so much. But I don't know the details. Issues have been raised numerous times in the EMF and/or Papyrus forum; googling may find you some useful details.
Myself, I always do my class modeling in UML, with Papyrus for diagrams. It’s like Ecore++: compatible with ECore, with several very useful extras.
Interesting. I didn't think of that. I'm using the ECore diagram editor to edit our XtUML-RT models. I suppose that to replace it with Papyrus one would use the UML import to create the EMF projects? How reliable is that import?
I would need migrate existing projects created with the Ecore Diagram Editor to Papyrus. This editor is based on Sirius, so I'd expect that we would have to remove the corresponding (Sirius-based) "represenations" (.aird) file.
We originally created these models in collaboration with IncQuery Labs. and Ericsson Hungary, using the Ecore Diagram Editor with its views and all that. Now, they have not been involved in it for a while, but I'm loath to make substantial modifications to plugins that may still be used by others and affect them and forcing them to switch to a different way of working with the models. If changing to Papyrus is not disruptive, I won't have a problem with it, but if it is disruptive, it might be better to avoid it.
I don't think any of these should be relevant. b) and c), strictly speaking, are not necessary, but it's a pain not to have them. But I couldn't do without a) and d).
My launch configuration is set to use "all workspace and enabled target plug-ins".
Yeah, I never do that. Only the features that are actually supposed to be in Papyrus(-RT). And certainly not the tests.
I do have some unrelated projects in my workspace, but I close them before launching. I do however keep the Papyrus-RT test bundles open. These shouldn't cause any trouble, should they? I would expect that the dev environment should work as smoothly as possible with whatever we have in the repo.
I don’t know about the Papyrus-RT tests, in particular, but there are Papyrus test bundles that add all sorts of weird extensions that make for a bizarre user experience in the tool.
In any case, the error is a very Papyrus-specific error. "Registry should be started before" ??? What sort of thing can cause Papyrus to raise that?
Attempt to get a service out of the ServicesRegistry of the model editor (or other usage of a ModelSet) before the registry has been started.
How do I do that? I don't see any options for the ServiceRegistry in either the Model Explorer or the Papyrus Preference pages.
But what component is doing that? Perhaps you can provide more of the stack.
See the trace at the end. It looks like it's the "ViewerSearchService".
I may change my launch configuration as you suggest, but that has the drawback that if something new is added, you have to remember to manually update the launch configuration, and in the past I fell for that. It's very easy to forget to update this.
That’s why assembling the launch config from features is so handy. Unless there’s a whole new feature to add, you can’t just forget a bundle here or there. And because, unlike Papyrus, Papyrus-RT doesn’t define features for the tests, you can probably just let the launch config find all features in your workspace and target, which gives you the best of both worlds.
Well, except that I already installed other stuff, so I have to either go through the list of features and make sure I select only the Papyrus-RT features, or start a new dev environment from scratch (again). In the past I tried it and things where still missing. Perhaps it's better now, but I just tried it, and did the following: 1) deselected all features (so that I wouldn't have the extras); 2) selected the oeprt feature; 3) clickes on "Select Required", and it only added the oeprt.common, .common.ui, .core, .cpp, .profile and .tooling features. It didn't add the .codegen, .rts, xtumlrt or compare features, or anything down the line, in particular it didn't add the Papyrus features or event the eclipse platform. Addint the oeprt.rcp feature resulted in no changes. What's more, even if I select all features, and I click on "Validate Plug-ins", it shows a bunch of validation errors, related mostly to oep.infra.gmfdiag.common and dependencies to something called 'org.apache.batik.*".
org.eclipse.papyrus.infra.core.services.BadStateException: Registry should be started before. (Service= 'org.eclipse.papyrus.infra.services.viewersearch.impl.ViewerSearchService', state= registered)
at org.eclipse.papyrus.infra.core.services.ServicesRegistry.getService(ServicesRegistry.java:406)
at org.eclipse.papyrus.infra.core.utils.AbstractServiceUtils.getService(AbstractServiceUtils.java:117)
at org.eclipse.papyrus.infra.gmfdiag.navigation.ui.DynamicNavigate.getViewsToSelect(DynamicNavigate.java:120)
at org.eclipse.papyrus.infra.gmfdiag.navigation.ui.ModelExplorerDynamicNavigate.fill(ModelExplorerDynamicNavigate.java:50)
at org.eclipse.ui.internal.menus.DynamicMenuContributionItem.fill(DynamicMenuContributionItem.java:147)
at org.eclipse.jface.action.MenuManager.doItemFill(MenuManager.java:728)
at org.eclipse.jface.action.MenuManager.update(MenuManager.java:810)
at org.eclipse.jface.action.MenuManager.handleAboutToShow(MenuManager.java:472)
at org.eclipse.jface.action.MenuManager.access$1(MenuManager.java:465)
at org.eclipse.jface.action.MenuManager$2.menuShown(MenuManager.java:497)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:256)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4248)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1501)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1524)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1505)
at org.eclipse.swt.widgets.Menu.menuWillOpen(Menu.java:805)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:5779)
at org.eclipse.swt.internal.cocoa.OS.objc_msgSend(Native Method)
at org.eclipse.swt.internal.cocoa.NSMenu.popUpContextMenu(NSMenu.java:77)
at org.eclipse.swt.widgets.Menu._setVisible(Menu.java:267)
at org.eclipse.swt.widgets.Display.runPopups(Display.java:4149)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3691)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$4.run(PartRenderingEngine.java:1121)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1022)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:150)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:687)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:604)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:138)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
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:388)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:673)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:610)
at org.eclipse.equinox.launcher.Main.run(Main.java:1519)
at org.eclipse.equinox.launcher.Main.main(Main.java:1492)
