As I see it, providing only platform-specific artifacts makes it difficult or impossible for third-party JavaFX libraries or frameworks to depend on the JavaFX API and pass it along to consumers. Libraries don't care about the platform-specific code - that's up the final application to determine - but are forced to arbitrarily choose one of the Windows, Mac, or Linux JARs anyway. I suppose they could use a compileOnly configuration, but that forces all downstream consumers to re-declare the JavaFX dependencies (and keep track of the dependencies of the library, too!)
IMO it makes more sense to publish the general API classes into a classifier-less JAR (which are now the "empty JARs") and place the platform-specific classes and binaries in platform-specific artifacts with a different name. For example, JavaFX could have a "javafx-graphics" artifact for the platform-agnostic classes, and a `java-graphics-platform" for platform-specific code, with classifiers to specify the platform. This does run into the "empty JAR" issue again, but it'd be limited in scope to only the final application. -- Sam Carlberg
