I’m using javapackager to generate native installers for several services and GUI applications. I would be using it for some command line tools as well, but it doesn’t yet support “console” applications on Windows. I.e. you can’t make javapackager with javapackager. I’ve filed an issue for that already (it was closed as won’t fix, but thankfully it was reopened)
Javapackager is one of the most useful tools in the JDK, but it is mostly undocumented and has many usability issues. IMO, it tried to do way too much. The only thing it ever needed to do was the -deploy option. I run javapackager two ways, always from Gradle scripts, either via the javaFX Gradle plugin, or as an Exec task. The ability to have secondary launchers is great. The customization options for installers needs some work. I’ve filed several issues (and I could file more). E.g. background images for macOS .dmg must be different from background images used in macOS .pkg as they are serving entirely different purposes. Including custom resources in subdirectories is difficult and/or broken depending on the version of javapackager used (v9 is broken). On Windows .msi component rules are not followed making upgrades problematic. Install folders should be customizable by supplying custom wix files, etc. On Linux services should be handled with systemd or sysctl. (I can’t remember which is preferred at the moment, but I know it didn’t use what I needed.) I really like that we have javapackager and feel it is a very important addition to the JDK. I too would love if it could build for multiple platforms from a single platform, but I honestly don’t see that happening. It isn’t worth the trouble or effort - things like making a HFS+ .dmg for macOS from Windows isn’t realistic. We do NOT want some custom non-native installer (Though a .zip of an app bundle might work.) You would also need the native bits of the JRE for each platform anyway. It would be possible to have those files available on any platform, but the tools to build .deb, .rpm, .dmg, .msi, etc. are just never going to be available everywhere. Scott > On Nov 30, 2017, at 7:16 PM, Kevin Rushforth <kevin.rushfo...@oracle.com> > wrote: > > Hi Michael, > > We realized that the javapackger CLI JEP wasn't quite ready, and was out of > scope for JDK 10 anyway, so we withdrew it in order to file a new JEP later. > > Related to this, we are soliciting input as to how people are using the > javapackager (see Victor's question below). > > So we'd love to hear how you and others are using it, and for what kind of > applications. > > -- Kevin > > > Michael Hall wrote: >>> On Nov 29, 2017, at 5:18 PM, victor.droz...@oracle.com wrote: >>> >>> Hi, Mani. >>> >>> Thanks for providing the feedback! >>> We will consider adding more examples and more details in the docs as you >>> proposed(there is an arg named jvmOptions but that's not mentioned in the >>> table). >>> Looks like there is a bug when you specify systemWide=true on the MacOSX in >>> non-gui mode. Can you provide more details about that (like full cmd line)? >>> Actually, if you want you can clone the repo: >>> http://hg.openjdk.java.net/openjfx/10-dev/rt/ >>> (hg clone http://hg.openjdk.java.net/openjfx/10-dev/rt/) >>> and help to improve javapackager. Or you can just create Enhancements for >>> deploy/packager, as it's not always clear what users expect. >>> >>> >> >> Why was JEP 311 [1] Closed/Withdrawn? >> >> [1] http://openjdk.java.net/jeps/311 >> >>
