The native libraries are quite large -- especially jfxwebkit -- and it
does seem better to have per-platform jar files, at least for the native
libraries. The following modules could be platform-independent since
they have no natives:
javafx.base
javafx.controls
javafx.fxml
javafx.swing
We would just need to test that the set of modular jar files for each
platform are the same, and then pick one (Linux?) to use for generating
the platform-independent jar files.
The following modules have native libraries:
javafx.graphics (*)
javafx.media (*)
javafx.web
(*) - also has some differences in the set of class files that are
included depending on the platform
So per-platform versions of the above would be needed to accommodate the
different native libraries.
If it would help, the .class files could be always included for all
platforms, but there would be some additional effort to make this work.
Also, it might be just as easy to have the class files and the natives
in one downloaded jar file per platform, since at least the natives need
to be platform-independent. I'm far from a maven expert, though, so I
don't really know for sure which path is easier.
-- Kevin
On 4/30/2018 9:44 AM, Paul Ray Russell wrote:
>I'm not sure I understand the question about platform-specific jar files,
Last time I worked on native specifics (which was to package up RXTX dlls
for different OSs / in 64/32 bit) The easiest solution for pure Maven
builds seemed to be, to package DLLs inside a jar. We then used a profile
to control which DLL's were grabbed in different cases. And surely for this
specific case, it would be better to split the native specifics into
separate jars per OS to avoid a huge cross-OS download?
