STS4 Does Not Start After Installing Papyrus Plugin

[WoodenCode00]

Absolutely new installation of STS 4.7.0 does not start anymore after installing Payrus for UML plugin v. 4.8.0.202006100749. Attached is log file that was generated in STS workspace folder.
From the log we can see that the root cause exception is :

!ENTRY org.eclipse.osgi 4 0 2020-07-02 00:33:11.207
!MESSAGE Application error
!STACK 1
java.lang.NullPointerException
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1091)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1047)
	at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:155)
	at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:658)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:557)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:154)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:150)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:203)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:137)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:107)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:401)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:255)
	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:657)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:594)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1447)

!ENTRY org.eclipse.gmf.runtime.common.ui 4 0 2020-07-02 00:33:11.262
!MESSAGE FrameworkEvent ERROR
!STACK 0
org.osgi.framework.BundleException: Exception in org.eclipse.gmf.runtime.common.ui.internal.CommonUIPlugin.stop() of bundle org.eclipse.gmf.runtime.common.ui.
	at org.eclipse.osgi.internal.framework.BundleContextImpl.stop(BundleContextImpl.java:920)
	at org.eclipse.osgi.internal.framework.EquinoxBundle.stopWorker0(EquinoxBundle.java:1029)
	at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.stopWorker(EquinoxBundle.java:370)
	at org.eclipse.osgi.container.Module.doStop(Module.java:660)
	at org.eclipse.osgi.container.Module.stop(Module.java:521)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.decStartLevel(ModuleContainer.java:1886)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1761)
	at org.eclipse.osgi.container.SystemModule.stopWorker(SystemModule.java:275)
	at org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle$EquinoxSystemModule.stopWorker(EquinoxBundle.java:202)
	at org.eclipse.osgi.container.Module.doStop(Module.java:660)
	at org.eclipse.osgi.container.Module.stop(Module.java:521)
	at org.eclipse.osgi.container.SystemModule.stop(SystemModule.java:207)
	at org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle$EquinoxSystemModule$1.run(EquinoxBundle.java:220)
	at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.NullPointerException
	at org.eclipse.gmf.runtime.common.ui.util.UIModificationValidator.dispose(UIModificationValidator.java:208)
	at org.eclipse.gmf.runtime.common.ui.internal.CommonUIPlugin.stop(CommonUIPlugin.java:84)
	at org.eclipse.osgi.internal.framework.BundleContextImpl$4.run(BundleContextImpl.java:900)
	at org.eclipse.osgi.internal.framework.BundleContextImpl$4.run(BundleContextImpl.java:1)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.eclipse.osgi.internal.framework.BundleContextImpl.stop(BundleContextImpl.java:892)
	... 13 more
Root exception:
java.lang.NullPointerException
	at org.eclipse.gmf.runtime.common.ui.util.UIModificationValidator.dispose(UIModificationValidator.java:208)
	at org.eclipse.gmf.runtime.common.ui.internal.CommonUIPlugin.stop(CommonUIPlugin.java:84)
	at org.eclipse.osgi.internal.framework.BundleContextImpl$4.run(BundleContextImpl.java:900)
	at org.eclipse.osgi.internal.framework.BundleContextImpl$4.run(BundleContextImpl.java:1)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.eclipse.osgi.internal.framework.BundleContextImpl.stop(BundleContextImpl.java:892)
	at org.eclipse.osgi.internal.framework.EquinoxBundle.stopWorker0(EquinoxBundle.java:1029)
	at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.stopWorker(EquinoxBundle.java:370)
	at org.eclipse.osgi.container.Module.doStop(Module.java:660)
	at org.eclipse.osgi.container.Module.stop(Module.java:521)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.decStartLevel(ModuleContainer.java:1886)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1761)
	at org.eclipse.osgi.container.SystemModule.stopWorker(SystemModule.java:275)
	at org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle$EquinoxSystemModule.stopWorker(EquinoxBundle.java:202)
	at org.eclipse.osgi.container.Module.doStop(Module.java:660)
	at org.eclipse.osgi.container.Module.stop(Module.java:521)
	at org.eclipse.osgi.container.SystemModule.stop(SystemModule.java:207)
	at org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle$EquinoxSystemModule$1.run(EquinoxBundle.java:220)
	at java.lang.Thread.run(Unknown Source)

sts4.log

[kdvolder]

I'm seeing a lot of package-use conflicts in the error log, this is most likely the cause of the problems. These problems tend to be the result of a particular combination of plugins being installed at the same time. Can you please provide precise details on what you install i.e. what distribution/package/download do you start from and exactly what extensions, do you install into it?

If you gives us precise set of steps we can try to reproduce the problem and investigate.

[WoodenCode00]

What I'm doing is:

• install STS4 4.7.0.RELEASE
• right after, Install Software / search for Papyrus for UML plugin (current version is v. 4.8.0.202006100749) and install it. Papyrus installation seems to be correctly completed, I did not see any error messages
• restart STS - it did not start

This error always happens. So basically in my STS installation Papyrus for UML is the only plugin I installed. And this is a new laptop so there are no traces of previous STS versions.

[kdvolder]

Sorry, still not totally clear because there are number of different ways to 'install STS4 4.7.0.RELEASE'. Are you downloading a full distribution bundle of STS? Or are you installing it into an Eclipse instance via the Eclipse marketplace? If the latter, what version of Eclipse is being used as the 'base' for this installation?

[WoodenCode00]

I donwloaded a JAR from Spring site
https://download.springsource.com/release/STS4/4.7.0.RELEASE/dist/e4.16/spring-tool-suite-4-4.7.0.RELEASE-e4.16.0-win32.win32.x86_64.self-extracting.jar

I did not install Eclipse, and Eclipse were never installed earlier on this machine (Windows 10).

[kdvolder]

Sorry to keep coming back to this but I have no idea which is the plugin you refer to as Papyrus for UML. I searched Eclipse marketplace as well as google. While there are good number of things that show up there's not a single one that is called 'Papyrus for UML'.

For example here's a search of Eclipse marketplace:

https://marketplace.eclipse.org/search/site/papyrus%2520for%2520uml

Is any of these the one that you installed?

[WoodenCode00]

I installed it through the command menu Help / Install New Software...
This is a screenshot:

[WoodenCode00]

If helps, it is Papyrus home page: https://www.eclipse.org/papyrus/download.html

[BoykoAlex]

Papyrus has installed fine for me in my STS 4.7.0 on eclipse 4.16.

Try perhaps opening a brand new workspace.

Note that stack trace does not point to anything in STS but rather GMF which the dependency for Papyrus... Perhaps try asking GMF or Papyrus folks what might have gone wrong...

[martinlippert]

I am able to reproduce this issue, starting with a fresh STS4 4.7.0 distribution on my macOS, switching that to run on a JDK8 (the Oracle JDK 1.8.0_251 in my case), and installing the Papyrus UML feature from the main Eclipse repo. After that, the IDE doesn't start. Instead it seems to do something in the background for a very long time (minutes), before it shows the dialog to select the workspace, and then fails with similar errors as you have in your.log file.

The reason seems to be a problematic package use conflict among several bundles. We need to investigate in more detail what exactly causes the dependency resolver to screw this up here.

The workaround that worked for me is to manually start the IDE from the command line with the -clean option. That causes the runtime to re-resolve all the dependencies and that computes a dependency graph that doesn't have the previous issues. Hope that workaround works for you @WoodenCode00, too. Can you try that?

[martinlippert]

(btw, the JDK that you run the IDE on might make an important difference here, since the OSGi dependency resolving of the javax packages works differently on JDK8 than on JDK9 and above (due to the JDK module system).

[kdvolder]

Though the errors look a little different, it sounds similar in many ways to https://bugs.eclipse.org/bugs/show_bug.cgi?id=564475

I.m.o if -clean solves the issue this implies there isn't actually a problem with the particular combination of plugins and resolution contstraints they imply, but rather a issue with the resolver getting stuck somehow in a state where it incorrectly thinks those contstraints are 'unresolvable' when in fact they are solveable after all.

[martinlippert]

@kdvolder That might be true, but nevertheless we should probably try to make it easier for the resolver and avoid the Require-Bundle dependency on org.eclipse.core.runtime. This causes issues again and again and also causes the resolution to behave differently when running on different JDKs. So not defining that dependency in such a way might help - independent of the way the resolver deals with dependencies when you install additional plugins (which is slightly different from running with the -clean option, maybe for a good reason).