JavaFX dependencies via a ComponentMetadataRule instead of the JavaFX Gradle Plugin

Help/Discuss
1

Greetings,

I’m trying to see if I can use a ComponentMetadataRule to properly resolve JavaFX dependencies as they’re currently packaged and published to Maven Central.

I’ve been using the JavaFX Gradle Plugin for this, but it has a few downsides. It doesn’t support specifying the correct dependency configurations (e.g. “api”, “implementation”) on a per-dependency basis. It also has no support for obtaining dependency variants for operating systems and architectures other than the one currently being used for the build, which I need to do in order to build distributions of my application for other platforms. Lastly, I’m thinking a ComponentMetadataRule may be a more performant and synergistic approach than the plugin’s current implementation. It seems more like the “right” way to do this. If I can get this to work I’m thinking to suggest it as an alternative approach for a future implementation of the JavaFX Gradle Plugin.

My alpha attempt is to simply add the missing classified native platform transient dependencies for each JavaFX component (e.g. “org.openjfx:javafx-base:19:win” for “org.openjfx:javafx-base:19”) for the current build OS and architecture (which I’ve even hardcoded rather than detected to start). As published, the classifiers for each native dependency declaration are ${javafx.platform} substitution variables for properties added by profiles in the parent POM, which I don’t believe Gradle understands and processes when resolving them.

I’ve reviewed the documentation extensively, but my initial ComponentMetadataRule attempt isn’t working. I’ve tried adding the native dependencies to the inferred “compile” and “runtime” variants for all the non-classified JavaFX components, but I’m still getting “Unresolved reference: javafx” errors trying to compile.

I have a minimal reproducer here: javafx-gradle-configuration/build.gradle.kts at 45784ee756551e76dc6788c9de2907a8720c2053 · ianbrandt/javafx-gradle-configuration · GitHub.

I’ve probably just misunderstood and misused the API somewhere. If someone could point out my mistake I’d greatly appreciate it.

2

I got it to work by adding the native JARs as additional files to the “compile” and “runtime” variants instead of trying to add them as additional classified dependencies: Changed approach to adding the files for the native variants instead … · ianbrandt/javafx-gradle-configuration@41e62f1 · GitHub.

3

For reference: The JavaFX plugin now has such a rule, which can be used by applying the plugin or by just using the rule from the plugin without applying it fully:

One may write such a rule in a bit more compact way using the org.gradlex.jvm-dependency-conflict-resolution plugin, like this:

1 Like
4

Hi Jendrik,

Thank you for following up on this. I finally got around to trying to update my project to the 0.1.0 version of the JavaFX Gradle Plugin. I ran into a couple issues that pushed me towards a slightly different approach. I’ve updated my original prototype with the approach I’m now using, and documented everything in the README: GitHub - ianbrandt/javafx-gradle-configuration.

Feedback welcomed. Of note, I didn’t pay any attention to backwards compatibility with past Gradle versions, nor to suitability for publishing as an independent plugin, as neither was necessary for my internal use case. If anything from my approach is seen as a potential improvement, I could file corresponding issues against the JavaFX Gradle Plugin proper.