I'd love to hear a general recommendation from the jigsaw team as well. Clearly, there are a number of solutions, and as a developer, I easily get confused if some frameworks do it with option A and others with option B. So what is the preferred approach in general?
It seems (given the large size of the webkit native library) there is a growing consensus here for bundling native code inside platform-specific jars? - Johan On Tue, May 1, 2018 at 7:38 AM Phil Race <philip.r...@oracle.com> wrote: > You are describing the situation today and making it into a contract. You > need to be sure that it is policed and enforceable. > Meaning there need to be tests to ensure it stays that way and that it is > not an unreasonable constraint on changes in the platform. > > Also what if anything do the jigsaw team recommend ? > > -Phil. > > > On Apr 30, 2018, at 4:07 PM, Kevin Rushforth <kevin.rushfo...@oracle.com> > wrote: > > > > 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? > > > >
