search

openjfx / javafx-gradle-plugin

Gradle plugin that makes it easy to work with JavaFX 11+
https://openjfx.io/
BSD 3-Clause "New" or "Revised" License
354 stars 62 forks source link

JavaFX plugin forces Gradle to put libraries on the modulepath instead of the classpath for whitebox unit tests #133

Open gleguern opened 2 years ago

gleguern commented 2 years ago

From the Gradle documentation on whitebox unit testing, the simplest setup for whitebox/unit testing is not to include a module-info.java file for the test sourceset (src/test/java). In this case, all tests get compiled with all dependencies in the classpath (and not modulepath).

The OpenJFX plugin (org.openjfx.javafxplugin) messes up with this setting by moving every dependency in the classpath to the modulepath, independently from the fact that the compiled test sourceset contains or not a module-info.java file.

An MCVE describing the issue is available at https://gitlab.com/mko-mcve/mcve-gradle-junit-scala-jpms/-/tree/openjfxPluginPb. The problem is detailed in https://gitlab.com/mko-mcve/mcve-gradle-junit-scala-jpms/-/blob/openjfxPluginPb/README.md#openjfxs-plugin-always-treats-unit-test-compilations-as-modular. This MCVE does not use any JavaFX code, the bug is triggered by the plugin itself (which is a really useful plugin for projects using OpenJFX and Gradle).

To experiment the effect of the bug, comment or uncomment the line id 'org.openjfx.javafxplugin' version '0.0.13' in the file ./Core/build.gradle; and run ./gradlew clean test in each case (./gradlew run always works even if the OpenJFX plugin modifies the classpath and modulepath arguments set up by other plugins).

Under Linux, to get a better understanding of what gets executed, in each case, run the command ./localScripts/captureBuggyCommands.sh (check its content before running it).

gleguern commented 2 years ago

It seems the OpenJFX plugin is modifying the classpath and modulepath arguments. It would probably be better if it only modifies the declared dependencies and let Gradle compute the correct classpath and modulepath from those declared dependencies.

abhinayagarwal commented 2 years ago

Yes, this might be the correct approach. This plugin was written when Gradle didn't have inherent support for JPMS. Now that it has, there might be a few things that can be changed in the plugin.

@gleguern Would you be interested in providing a fix?

gleguern commented 2 years ago

Hi, I do not have much time right now to work on it. But if the problem is still present when I have time to work on it, I may try to provide a fix.

ianbrandt commented 1 year ago

I've been working on a Gradle-native approach that only contributes dependency configuration via a ComponentMetadataRule, and leverages Gradle's built-in JPMS support otherwise: https://github.com/ianbrandt/javafx-gradle-configuration.

My primary use case is a Kotlin+Java project that would need to be incrementally migrated to JPMS. Accordingly, my progress on this is currently stalled by the related Kotlin Gradle Plugin and IntelliJ issues noted in the README: https://github.com/ianbrandt/javafx-gradle-configuration#upstream-issues. Any additional votes on those upstream issues could help get them prioritized, which would facilitate me moving forward.

I'd love to see a future version of this plugin that is reimplemented to package up the approach I'm prototyping. I'd be happy to make any licensing accommodations or execute a contributor agreement as needed.

nlisker commented 1 year ago

Is there any update on this? The plugin messes up gradle projects.

jjohannes commented 1 year ago

I stumbled over this recently. It would be good if the plugin won't depend on the org.javamodularity.moduleplugin plugin. Which is responsible for this issue. That plugin is not really compatible with Gradle's built-in Module System support (and other plugins relying on that).

One thing you could do right now is not use this plugin, but instead add the JavaFX dependencies as normal Gradle dependencies. You have to deal with the different native variants. There are good solutions for this in Gradle by now (which JavaFX and this plugin do not yet employ). I try to explain what you can do here: https://github.com/gradle/gradle/issues/26144#issuecomment-1686037462

I might have a look at the plugin code and propose some kind of improvement.

leeca commented 1 year ago

I was having exactly this problem. Due to the JavaFX gradle plugin v0.0.14 behavior if forcing all Jar files onto the module path, XStream was unable to instantiate the provider for the XmlPull service.

Switching to JavaFX gradle plugin v0.1.0 solves the problem. I recommend closing the issue as fixed.