An all-in-one solution does exist when using OpenJFX as an SDK instead as dependencies from Maven/Gradle.
There was a discussion about empty JARs here on the mailingslist. A problem it seemed to be with Gradle and Eclipse The Gradle build instruction for Java 11 suggest setting platform as a classifier, thus taking only the one from the platform. compile "org.openjfx:javafx-base:11:${platform}" compile group: "org.openjfx", name: "javafx-base", version: "11", classifier: platform https://openjfx.io/openjfx-docs/#gradle Den tor. 20. sep. 2018 kl. 16:20 skrev Geir Helleloid < geir.hellel...@gmail.com>: > I am working on moving my company's codebase from Java 8 to Java 11. > Our build/deployment pipeline uses Maven, Jenkins, an internal Nexus > repository, and custom deployment code. We deploy our software to > multiple platforms (Linux, Windows, and Mac). > > I am wondering how to handle the JavaFX 11 dependencies for > cross-platform deployment. I cannot just declare a dependency on (for > example) org.openjfx:javafx-graphics:11 in our poms; the Jenkins build > will only pull in the platform-specific > org.openjfx:javafx-graphics:11:linux dependency, and deployment from > Nexus to Windows or Mac will not include > org.openjfx:javafx-graphics:11:win or > org.openjfx:javafx-graphics:11:mac. > > I could explicitly declare org.openjfx:javafx-graphics:11:linux, > org.openjfx:javafx-graphics:11:win, AND > org.openjfx:javafx-graphics:11:mac as dependencies in our poms. Then > all three dependencies would be deployed to every platform, but JavaFX > would use the appropriate one at runtime. Not only is this clunky, but > I think(?) that it fails if we switch to using the module path instead > of the classpath, since there will be split/overlapping packages. That > suggests that our custom deployment code needs special handling to > only deploy the correct JavaFX artifacts for the target platform (or > to set up the classpath to only include the correct JavaFX artifacts). > Perhaps this is avoidable by building an uber-jar of JavaFX > dependencies with the maven-shade-plugin, although I believe the > maven-shade-plugin will at least spit out a lot of warnings about the > overlapping packages. > > I think one solution to all of this is for OpenJFX is to provide > org.openjfx:javafx-{name}:11:all artifacts that contain all the code, > include the platform-specific code for each platform, but those do not > currently exist. > > I would love to hear how other people are handling this situation. Am > I misunderstanding the situation? Is there a good (obvious or > non-obvious!) solution that I'm missing? Is there something about this > scenario that is atypical? (My guess is that this is a very typical > scenario.) > > Thanks, > Geir Helleloid >