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.