Re-familiarizing myself with what javapackager offers, it seems the following JavaFX related features are present:
1.) The conversion of CSS to binary CSS 2.) The ability to specify a preloader 3.) the ability to specify the JavaFX Application class The first one seems like a bit of feature-creep and could be replaced by some other build tool if third party developers really need that feature. They could probably even use something like maven-exec-plugin to manually call such a converter. Let's set this one aside, then. The second and third one are important for correctly launching a JavaFX application. I would think that in order for these to be easily accomplished flags would need to be present in "jpackager" for specifying them (namely, the preloader and Application class). Otherwise jpackager would need to do some "reflection" to try and determine whether or not JavaFX is being used (maybe by checking for its presence on the module path?) and then, if so, get the appropriate preloader and application class. I only mention this because the JEP proposal specifically states "JavaFX-specific features" under "Non-Goals" but this might make things more complicated than they need to be in those two areas I mentioned above. Other then that, this looks good to me and I think having a replacement for javapackager is a good idea. Thanks, Michael Ennen On Thu, May 31, 2018 at 1:56 PM, Kevin Rushforth <kevin.rushfo...@oracle.com > wrote: > The existing javapackager doesn't really know much about JavaFX as it is, > now that applet and Web Start are gone. I am not aware of anything that > would preclude packaging up a JavaFX application. We will certainly test > the ability to package up a JavaFX application. > > As for the schedule, I agree it isn't ideal, but it's too late for JDK 11. > > -- Kevin > > > > On 5/31/2018 1:25 PM, Michael Paus wrote: > >> Hi, >> >> is it possible to get a clear statement on whether it will be possible to >> package a JavaFX application with the new packager in a similar way as it >> is possible right now with the old packager? The texts are a little bit >> vague there. I just don't know whether it is possible to create a packager >> which does not know anything about the GUI framework which has been used by >> an application. >> >> I would also like to express my concerns about the schedule. The next >> Java release (11) will be an LTS release and that means that there will not >> be any packager for all those people who will have to stick with this >> release for a long time. This is a huge step backward for Java because >> there is then no good deployment technology anymore for a long time. >> >> Michael >> >> Am 31.05.18 um 02:11 schrieb Kevin Rushforth: >> >>> I just sent an email to the core-libs-dev alias [1] proposing a new >>> Packaging Tool as a replacement for javapackager. If you are interested in >>> this JEP, you can follow and participate in the discussion there. >>> >>> -- Kevin >>> >>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-Ma >>> y/053503.html >>> >>> >> >
