Error initializing QuantumRenderer: no suitable pipeline found in version 0.1.0 on mac m1

[Siedlerchr]

I tested this plugins newest version 0.1.0, however, when I tried to start the application using ./gradlew run I got the folllowing error:

Version 0.14 still works: I am using a mac m1 I created a PR/branch for reproducing at our project https://github.com/JabRef/jabref/pull/10339

Graphics Device initialization failed for :  es2, sw
Error initializing QuantumRenderer: no suitable pipeline found
java.lang.RuntimeException: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found
        at javafx.graphics@20/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:283)
        at javafx.graphics@20/com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:253)
        at javafx.graphics@20/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:263)
        at javafx.graphics@20/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:290)
        at javafx.graphics@20/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:162)
        at javafx.graphics@20/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:651)
        at javafx.graphics@20/com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:671)
        at javafx.graphics@20/com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:195)
        at java.base/java.lang.Thread.run(Thread.java:1623)
Caused by: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found
        at javafx.graphics@20/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:95)
        at javafx.graphics@20/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125)
        ... 1 more
2023-09-06 20:44:37 [main] org.jabref.cli.Launcher.main()
ERROR: Unexpected exception: java.lang.RuntimeException: No toolkit found
        at javafx.graphics@20/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:275)
        at javafx.graphics@20/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:290)
        at javafx.graphics@20/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:162)
        at javafx.graphics@20/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:651)
        at javafx.graphics@20/com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:671)
        at javafx.graphics@20/com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:195)
        at java.base/java.lang.Thread.run(Thread.java:1623)

[jperedadnr]

Do you have non-modularized dependencies in your project? See #154 ?

[Siedlerchr]

Hi, yes, there are a few ones. We also have a third-party scala libary (scala does not support jigsaw fully) and we already have the modularizer plugin in our build gradle: This combination works, however, just upgrading openjfx plugin doesn't. https://github.com/JabRef/jabref/blob/1ed081f4e9c2e0f19719ea056eec868c50fcd4f1/build.gradle#L12-L14

[jperedadnr]

Maybe you also need what I mentioned here: https://github.com/openjfx/javafx-gradle-plugin/pull/154#discussion_r1317753483

[Siedlerchr]

That is also disabled: https://github.com/JabRef/jabref/blob/1ed081f4e9c2e0f19719ea056eec868c50fcd4f1/build.gradle#L43-L63

Edit//. We also need to configure some exports for run configuration:

https://github.com/JabRef/jabref/blob/1ed081f4e9c2e0f19719ea056eec868c50fcd4f1/build.gradle#L347-L391

[jperedadnr]

Pinging @jjohannes, he might find if the issue is related to the recent changes.

[samypr100]

I gave it a quick shot and cloned the repo and switched to the updatejfxplugin branch. Since I have a clean system luckily I can rule out the repositories { mavenLocal(), ... } I saw from potentially affecting me.

I managed to get it to work at the end, here's a few observations.

1. I had a clean system. M2 OSX.
2. I ran assemble first, and the first thing I noticed was javafx-{base,control,etc.}-{linux,mac-aarch64}.jar mixed in. Meaning there were both linuxand mac-aarch64 mixed.
3. I hypothesized that there was a possibility of a dependency briging in classified javafx jars, so I proceeded to exclude group: 'org.openjfx' on all dependencies I could find that brought JavaFX (via ./gradlew dependencies). Namely, org.jabref:afterburner.fx, com.tobiasdiez:easybind, com.dlsc.gemsfx, org.controlsfx:controlsfx.
4. After this, running the distribution from assemble worked for me. I also tried run and it worked as well.

I'm not sure what the result would be from a dependency with a classfied JavaFX jar via thirdPartyCompatibility in the Gradle Module Metadata could do after the update to 0.1.0 but likely the issue lies around that. My initial wild guess is that the external classified dependency is causing issues.

[Siedlerchr]

Thanks for the info! We will try this ASAP

[jjohannes]

The analysis @samypr100 did is correct. I Believe the only issue is with org.jabref:afterburner.fx:1.1.0-SNAPSHOT though (https://s01.oss.sonatype.org/content/repositories/snapshots/org/jabref/afterburner.fx/1.1.0-SNAPSHOT/afterburner.fx-1.1.0-20221226.155809-7.module). @Siedlerchr if you would update the JavaFX plugin in the org.jabref:afterburner.fx as well and publish a new snapshot, the problem should be gone. It would be a better solution – solving the problem at the source – instead of adding excludes.

@samypr100 This could also be considered a "breaking" change in the plugin. The previous version rewrote the whole classpath/module path and removed the "wrong" transitive Jars. However, I think I would keep it like this. If problems like this occur, the library authors should be informed to publish a patch with fixed metadata. And as an intermediate solutions users might us "exclude" to deal with the wrong metadata. This might be worth a mention in the migration notes (#154).

[Siedlerchr]

I published a new snapshot of the afterburner with the new plugin and now it works fine. Thanks again for the support!