CI fails to build Eclipse plugins which require Java 11

[fvgh]

With version CDT 10.0.0 and WTP 3.21.0, the corresponding Eclipse plugins require Java 11.
Note that the WTP version has not been released yet. The CDT build worked until 56cce95

The reason for the change is unknown.

On my local development machine I got with JDK 11 the following error:

Caused by: java.lang.reflect.InvocationTargetException
at com.diffplug.gradle.eclipserunner.JarFolderRunner.run(JarFolderRunner.java:51)
at com.diffplug.gradle.eclipserunner.JarFolderRunnerExternalJvm$RunOutside.run(JarFolderRunnerExternalJvm.java:126)
at com.diffplug.gradle.JavaExecable.main(JavaExecable.java:134)
Caused by: java.lang.SecurityException: class "org.osgi.service.log.LogLevel"'s signer information does not match signer information of other classes in the same package
at org.eclipse.osgi.internal.log.EquinoxLogServices.(EquinoxLogServices.java:94)
at org.eclipse.osgi.internal.framework.EquinoxContainer.(EquinoxContainer.java:78)
at org.eclipse.osgi.launch.Equinox.(Equinox.java:34)
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:315)
at com.diffplug.gradle.eclipserunner.EquinoxLauncher$Running.(EquinoxLauncher.java:196)
at com.diffplug.gradle.eclipserunner.EquinoxLauncher$Running.(EquinoxLauncher.java:189)
at com.diffplug.gradle.eclipserunner.EquinoxLauncher.open(EquinoxLauncher.java:174)
at com.diffplug.gradle.eclipserunner.EquinoxLauncher.run(EquinoxLauncher.java:179)
... 3 more

So maybe the reason to use JDK 8 was just a problem with com.diffplug.p2.asmaven.
In my local environment I just worked around by using

id 'com.diffplug.eclipse.resourcefilters' version '3.26.1'

instead of

id 'com.diffplug.eclipse.resourcefilters' version '3.29.1'

[fvgh]

@nedtwigg , since 56cce95 was your commit and I remember vaguely that there were some issues with com.diffplug.p2.asmaven regarding later Eclipse versions, can you refresh my memory?

[nedtwigg]

Shoot, sorry if I gunked up your workflow. Here's the short version of the goomph changelog:

• 3.26.1 and 3.27.0 are equivalent as far as p2asmaven, and are the last "proven" p2asmaven. I am fine with reverting back to 3.27.0
• The problem with them is that the ide task doesn't work with 4.17 or later, but that's less important than your CDT and WTP workflows.
• 3.28.0 fixes ide, but breaks p2asmaven
• 3.29.1 fixed p2asmaven again, but only if you're running Gradle with JDK 8.

I don't think that p2asmaven will ever work with JDK 11+ in future versions of Goomph. I burned a lot of time on it, a few other people did too, Eclipse startup is just a tricky thing to debug if it goes wrong.

Sounds like you need both a working p2asmaven and to write and build against JDK11. I think there's two options:

1. Revert goomph to 3.27.0 (basically same as 3.26.1), which I'm fine with
2. Use latest goomph and run gradle with JDK 8, but use the java toolchain feature to spec that JDK 11 should be used for building and testing the code that you write (while JDK 8 is used just for running the Gradle script).

I think that option 2 will work and be more durable in the long-term, but I'm fine with option 1 as well.

[fvgh]

Using java toolchain feature is quite expensive:

• feature not available in Gradle version 6.6. Recommended switched to 6.8.
• feature does not work in combination with sourceCompatibility \ targetCompatibility. Refactoring to options.release required.
• p2asmaven runs during project configuration and fails without any useful error message (sorry, stack trace does not count) if user uses not JDK 8. Hence, the need for JDK 8 should be documented.
• java toolchain feature is not transparent to IDE. Configuration in Eclipse is complex.

I am preferring the first option for now.

[nedtwigg]

Sounds good. Easy to revisit this in the future if some future version of Goomph has something we want that 3.27.0 does not. Very helpful to have the list of cons you outlined above to help guide that future discussion if it ever happens.