Geir Helleloid
2018-09-20 14:20:13 UTC
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
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