[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: Cross-platform JavaFX 11 deployment
From:       Sverre Moe <sverre.moe () gmail ! com>
Date:       2018-09-20 19:08:11
Message-ID: CALAJ+5BYG+RSgVDQsUeL_AXyK3-xow86eDHMmoZuArf5f8i6mQ () mail ! gmail ! com
[Download RAW message or body]

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.helleloid@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
>
[prev in list] [next in list] [prev in thread] [next in thread]