groovy-eclipse install and switch to 2.4 compiler causes Spring IDE to break

[martinlippert]

as reported in this issue here:
#148

the installation of Groovy-Eclipse and the switch to the 2.4 compiler causes other Spring IDE components to break.

Steps to reproduce:

• start with fresh STS 3.8.4
• install Groovy-Eclipse
• restart
• switch to groovy 2.4 compiler in the preferences
• restart

Spring IDE views refuse to open (like the boot dashboard or the spring explorer view) and throw an error instead.

java.lang.Exception
	at org.eclipse.ui.internal.ViewReference.createErrorPart(ViewReference.java:112)
	at org.eclipse.ui.internal.ViewReference.createPart(ViewReference.java:98)
	at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.createPart(CompatibilityPart.java:278)
	at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.create(CompatibilityPart.java:316)
	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.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:55)
	at org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:966)
	at org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:931)
	at org.eclipse.e4.core.internal.di.InjectorImpl.inject(InjectorImpl.java:151)
	at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:375)
	at org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:294)
	at org.eclipse.e4.core.contexts.ContextInjectionFactory.make(ContextInjectionFactory.java:162)
	at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.createFromBundle(ReflectionContributionFactory.java:105)
	at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.doCreate(ReflectionContributionFactory.java:74)
	at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.create(ReflectionContributionFactory.java:56)
	at org.eclipse.e4.ui.workbench.renderers.swt.ContributedPartRenderer.createWidget(ContributedPartRenderer.java:129)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createWidget(PartRenderingEngine.java:975)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:651)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$1.run(PartRenderingEngine.java:536)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:520)
	at org.eclipse.e4.ui.workbench.renderers.swt.ElementReferenceRenderer.createWidget(ElementReferenceRenderer.java:70)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createWidget(PartRenderingEngine.java:975)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:651)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:757)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.access$0(PartRenderingEngine.java:728)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$2.run(PartRenderingEngine.java:722)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:706)
	at org.eclipse.e4.ui.workbench.renderers.swt.StackRenderer.showTab(StackRenderer.java:1324)
	at org.eclipse.e4.ui.workbench.renderers.swt.LazyStackRenderer.postProcess(LazyStackRenderer.java:103)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:669)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:757)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.access$0(PartRenderingEngine.java:728)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$2.run(PartRenderingEngine.java:722)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:706)
	at org.eclipse.e4.ui.workbench.renderers.swt.SWTPartRenderer.processContents(SWTPartRenderer.java:70)
	at ...

[spring-projects-issues]

(comment in Pivotal Tracker added by Kris De Volder:)

I was able to reproduce. One would assume that this is some kind of a dependency issue between greclipse and STS components but that does not appear to be the case, because... When I restart STS again, the problem fixes itself.

So it would seem like the auto-restart performed by Greclipse doesn't quite startup Eclipse / STS properly.

[spring-projects-issues]

(comment in Pivotal Tracker added by Kris De Volder:)

Hmmm... subsequent compiler switches now also seem to be working properly.

[spring-projects-issues]

(comment in Pivotal Tracker added by Kris De Volder:)

At first it seemed like a restart fixed the issue somehow, but right now it seems to stay permanently broken. I have no errors related to bundle activation in the error log at all. I'm bit stumped what the problem is.

Here some of the things I found:

• Uninstalling greclipse fixes the problem.
• Things work fine (with greclipse installed) until the 'switch compiler' button from Greclipse preferences is used. I have had cases where it worked fine with 2.4 selected and broke on switching to 2.3. Also the other way around (i.e. it worked fine with 2.3 already active and then broke when I switched to 2.4) So it doesn't seem connected with the specific selected version of the compiler, but more likely connected to the switching mechanic (I seem to remember this being some kind of low-level osgi framework hook that intercepts osgi early on and then manipulates bundle activation somehow, based on some state saved in the workspace).
• Using -clean option doesn't seem to help.
• There are no osgi errors and as far as osgi seems concerned, the bundles seem to activate / resolve etc fine. (Disclaimer: I'm not a OSGI expert so maybe I just not looking at it the right way)

[spring-projects-issues]

(comment in Pivotal Tracker added by Kris De Volder:)

Got an error log from starting up in a broken workspace. There are some errors and warnings around something seems broken in OSGI (stuff like "invalid registry object" and "Could not run processor" and some things going amiss with Oomph).

Not sure this is connected to our problem, but seems somewhat likely at least.

[spring-projects-issues]

(comment in Pivotal Tracker added by Kris De Volder:)

The problem can be 'fixed' by deleting the greclipse compiler resolver settings here: /.metadata/.plugins/org.eclipse.core.runtime/.settings/org.codehaus.groovy.eclipse.compilerResolver.prefs which seems to confirm my suspicion that the greclipse compiler switching osgi magics have something to do with all of this.

[spring-projects-issues]

(comment in Pivotal Tracker added by Martin Lippert:)

I also took a closer look at this. It seems that the core Groovy bundle is calling "refreshPackages" on the OSGi package admin at some time during startup, to set the specified Groovy compiler bundle.

The package admin service is deprecated some quite some time. And I think it is quite dangerous to trigger the OSGi runtime to refresh packages during Eclipse startup. I think it is dangerous at all in an Eclipse IDE environment, since it is not built to be as dynamic as the OSGi runtime suggests it is.

I don't know enough about the Groovy compiler settings (and how all that works), but this piece looks dangerous.

[spring-projects-issues]

(comment in Pivotal Tracker added by Martin Lippert:)

I think the problematic piece starts here:
https://github.com/groovy/groovy-eclipse/blob/5bdf7b3dfdd31492dd4f844d3cc82282f4cf5c53/base/org.codehaus.groovy.eclipse.compilerResolver/src/org/codehaus/groovy/frameworkadapter/util/CompilerChooser.java#L123

[spring-projects-issues]

(comment in Pivotal Tracker added by Martin Lippert:)

If I understand the underlying logic correctly, a compiler switch uninstalls all the other compiler bundles and triggers the runtime to restart and to re-resolve bundles, so that other components get wired to the selected compiler bundle.

If that is correct, I would suggest to install/uninstall the bundles and then trigger a restart with "-clean". That should do everything that is needed. It should not be necessary to do anything else during startup.

Another option would be to define version constraints in the importing bundle and use a framework hook to specify that version range exactly to the version you selected at startup - and let the OSGi resolver do the rest. That way you would not need to install/uninstall bundles or re-wire packages or do anything dynamic (like refreshPackages) during startup.

[spring-projects-issues]

(comment in Pivotal Tracker added by Kris De Volder:)

@mlippert "... seems dangerous..." indeed. It took Andrew many many hours/days of fiddling and it has been fragile ever since.

The hard part I think is that it tries to switch around bundle installation / activation while osgi is in process of starting bundles. And it wants to satisfy two competing goals:

• be early enough so its not too late to fiddle with the groovy compiler bundles
• be late enough so that eclipse resources plugin is booted up so it can read compiler preference from the workspace.

So the problem is, I think, what you suggest is not possible because the compiler prefs live in the workspace. You can't simply uninstall the compiler bundles indescriminatley as it may be needed for some workspaces and not others.

Anyhoo... this is a problem in Greclipse most likely. Strange though how it seems to mostly break STS components and not anything (?) in Eclipse itself.

[mlippert]

I think the above comment was supposed to be for @martinlippert not for me.

[martinlippert]

@mlippert absolutely right... :-) Thanks!!!
I think it is a side effect of our issue sync among pivotal tracker and GitHub, because I am @mlippert on tracker... :-)