JEP 343: Packaging Tool

[Scott Palmer]

A couple comments inline...

> On Jun 5, 2019, at 5:16 PM, mark.reinhold at oracle.com wrote:
> 
> I saw that you moved JEP 343 to “Proposed to Target,” so I spent a
> couple of hours looking at it.  You’ve made good progress but I don’t
> think this is in the “nearly finished” state that we ask of features
> in the six-month cadence.  I suggest that you move this JEP back to
> Candidate for now and continue refining it.  The next feature release,
> JDK 14, is just six months away.
> 
> Some specific observations and suggestions:
> 
>  - At the moment there are 75 open issues in JBS [1], 69 of which are
>    P3 or higher.  JDK 13 will enter RDP 1 next week, so there’s not
>    much time to make progress on all those issues.

I get where you are coming from, but I feel I should point out how it looks like the JDK is moving backwards from my perspective. When JavaFX was bundled with Java 8, like it or not the distribution of Java from Oracke co rained a packager and there was no appearance that it was JavaFX-specific (because it wasn’t). The. That useful tool that devs came to rely on was removed and it won’t be replaced for how many major versions in a row now? Because it isn’t ready, even though you already had been shipping a packager tool that already had more features than the replacement. (E.g. creating a service)

> 
>  - The use of the term “installer” in the JEP and in the command-line
>    options is confusing.  The tool only creates installers on Windows
>    and macOS (pkg); the other formats that it supports (macOS dmg,
>    Linux deb/rpm) are OS-specific packages rather than interactive
>    installers.  Consider replacing the term “installer” with “package”
>    throughout.  This would also align better with the name of the tool
>    itself.
> 
>  - It’s not clear why there are distinct subcommands to create an image
>    vs. to create an OS-specific package.  Given the name of the tool,
>    I’d expect creating a package to be the primary behavior.  An option
>    to preserve the image, which is just a temporary result, could make
>    sense, as well as another option to skip the creation of the
>    package, but I don’t understand the need for subcommands.

I disagree with this. The primary reason to produce the image is because you will be incorporating it into your own installer with other things (part of a larger product, installer needs more custom options, etc.), or providing a simplified .zip distribution. 
Running the tool all the way to produce an installer/package that you are just going to throw away is a waste. On Windows MSI installers take forever to build.  So it would be a big waste if you had to wait for it. Two extra flags, one to say to preserve the “intermediate result” that was all you wanted, and another to disable creating the installer/package that you had to ask for in the first place to get the image. It’s awkward. Just have multiple target package types, including “image”. 

It is also very useful to be able to customize the image prior to generating the final package. (E.g. adding files in arbitrary subfolders, tweaking a generated file because of missing features in the packager tool, etc.). So building a package/installer from an image is important, and a naturally distinct step in the process already. 

Scott 
(Like most, I’m stuck on Java 8 until the dust settles.)

> 
>  - On a Debian machine I tried to create a package from a trivial,
>    two-module application using the command
> 
>      $ jpackage create-installer -o /tmp -p lib -m org.openjdk.hello -n hello
> 
>    This terminated with exit code 255 and an error message.  In Linux,
>    and Unix/POSIX generally, an exit code of 255 means that the exit
>    status was out of range.  I suggest you exit with the value 1 on
>    errors, at least on Linux.
> 
>  - The error message from the above command was:
> 
>      Bundler RPM Bundle skipped because of a configuration problem: Can not find rpmbuild 4 or newer..
>      Advice to fix: Install packages needed to build RPM, version 4 or newer.
> 
>    I’m on a Debian machine, trying to create an OS-specific (i.e.,
>    Debian) image, so this was a confusing message.  (Yes, I know it’s
>    possible to create rpms under Debian if you have the right tools
>    installed, but that’s not what I was trying to do here.)
> 
>  - What’s more, even though the tool exited on error it still produced
>    a Debian package in the output directory, but I found it only by
>    accident.
> 
>  - Looking at the content of the generated Debian package, the control
>    file has many fields that don’t have corresponding jpackage options.
>    That could be a problem for some developers.
> 
>  - The data in the Debian package would place the application into a
>    directory named `/usr/bin/hello`, which is completely wrong.  Please
>    see the Filesystem Hierarchy Standard [2] and the Debian Policy
>    Manual [3] for details.
> 
>  - I tried to create a package that would install into the `/opt`
>    directory by appending `--install-dir /opt` to the above command
>    line.  The data in the resulting package would indeed install into
>    `/opt`, but the structure within that directory would be incorrect.
>    There should be an `/opt/hello/bin` directory containing the `hello`
>    launcher, and the remainder of the content should be organized per
>    the usual conventions [4].
> 
> To get this into better shape I suggest that you seek advice and, when
> appropriate, reviews from developers who have deep experience with the
> rpm and deb package formats (there are several such people here in the
> OpenJDK Community).  It’d also be good to get feedback from macOS and
> Windows packaging experts, but I don’t personally know of any.
> 
> - Mark
> 
> 
> [1] https://bugs.openjdk.java.net/issues/?jql=project%20in%20(JDK)%20AND%20component%20in%20(tools)%20AND%20Subcomponent%20in%20(jpackage)%20and%20statuscategory%20not%20in%20(Done)
> [2] http://www.pathname.com/fhs/pub/fhs-2.3.html#USRBINMOSTUSERCOMMANDS
> [3] https://www.debian.org/doc/debian-policy/index.html
> [4] http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES