Comments on jpackage (JEP 343)

Wed Sep 4 19:47:09 UTC 2019

Hi Sverre,

Thank you for your feedback.

I've filed [1] bug to address Debian packaging issue.

As for your question regarding release number, it is not supported by 
WiX on Windows. See [2].
Also product version string should follow quite strict rules [3]. 
However you can encode release value in the third component of product 
version (build number) as a workaround on condition release is a number.

[1] https://bugs.openjdk.java.net/browse/JDK-8230612
[2] https://wixtoolset.org/documentation/manual/v3/xsd/wix/product.html
[3] https://docs.microsoft.com/en-us/windows/win32/msi/productversion

- Alexey

On 9/4/2019 5:53 AM, Sverre Moe wrote:
> I tired the latest build 14-jpackage+1-35 today. Good to see that debian
> package file name is finally up to the specification.
>
> Noticed something though with building the debian package:
> When using a control file from the resource directory, jpackage does not
> use its version and release.
> Must apply "--app-version" and "--linux-app-release" in order to get the
> proper version and release on file name.
>
> Running dpkg-deb --show and --info has the correct version and release.
>    dpkg-deb --show build/deb/application_1.0-1_amd64.deb
>    application 1.1.0-SNAPSHOT20190904113134
>
> I wonder where it gets the version 1.0 from, since my
> project.version=1.1.0. The jpackage should at least use the project version
> if no other version is specified.
>
> This is a problem only for the debian package on Linux. When building an
> RPM, jpackage uses both the Version and Release defined within the spec
> resource file.
>
> Isn't release also applicable for Windows and Mac?
> What about, instead of calling it "--linux-app-release", why not simply
> call it "--app-release". That would stand much better together with
> "--app-version".
> With "--linux-app-release" it makes it more more verbose when scripting the
> build, when it needs to check for Windows and Mac in order to omit that
> flag.
>
> /Sverre
>
>
> tir. 3. sep. 2019 kl. 21:01 skrev <mark.reinhold at oracle.com>:
>
>> I spent some time last week playing with the jpackage tool, using build
>> 14-jpackage+1-35 from https://jdk.java.net/jpackage.
>>
>> Overall, I can see that you’ve made good progress, but there’s still some
>> work to be done.  I’ll start with high-level comments and questions, and
>> then comment on my experience using the tool on Debian and then macOS.
>>
>> High-level comments/questions
>>
>>    - It’s good that you’re publishing EA builds, but I haven’t seen very
>>      much feedback from those builds.  It may be better to propose this as
>>      an experimental feature when it’s ready to target.  That would give
>>      you the freedom to improve it incompatibly over one or two release
>>      cycles before you commit to a final version.
>>
>>    - The tool still generates an image by default, rather than a package.
>>      This will surprise many users, especially those who just want to do
>>      something simple and straightforward.  The least-surprising default
>>      behavior would be to generate a package of the type most suitable for
>>      the current platform.  An option to generate just an image would be
>>      fine, for those who want to tweak it before the actual packaging
>>      step, but that shouldn’t be the default.
>>
>>    - Related to the previous point, I should only have to specify the
>>      `--package-type` option if I want something other than the default
>>      for the current platform.
>>
>>    - The tool assumes that the application being packaged will have a GUI.
>>      This isn’t surprising, considering its heritage, but as a consequence
>>      it always produces packages that perform GUI-specific actions, such
>>      as installing icons and desktop-menu entries.  If I’m just packaging
>>      a command-line tool then these are unnecessary, and supporting them
>>      can pull in lots of additional dependencies (e.g., a ton of Perl
>>      scripts on Debian).  Consider adding an option (`--gui`?) so that
>>      the user can indicate when an application is to be installed for
>>      graphical use.
>>
>>    - The `--output`/`-o` option is confusing.  It doesn’t name the output
>>      itself, but rather a directory into which the single item of output
>>      will be placed.  Typing `-o .` all the time is just annoying.  It’d
>>      be more logical to rename this option to `--dest`/`-d` and to make it
>>      optional, with a default value of `.`.
>>
>>    - If my app is modular, and my main module has a version string, then
>>      it’d be nice for that to be used as the package version unless a
>>      specific version is specified on the command line.
>>
>>    - Terminology: For Linux we generally speak of “packages” rather than
>>      “bundles.”  Rename `--linux-bundle-name` to `--linux-package-name`.
>>
>>    - The `--temp-root` option could be shortened to `--temp`.
>>
>>    - Periods at the ends of error messages are unsightly and unnecessary.
>>      We don’t use them in other JDK tools.  Please remove them.
>>
>>    - It’d be nice to have an option that displays the programs being run
>>      by the tool, in a form that can easily be cut-and-pasted into a
>>      script for those who need to do a lot of customization.  The current
>>      verbose output shows (at least some of) this information, but in a
>>      difficult-to-use format.
>>
>>    - What’s the rationale for copying the entire “input” directory as-is?
>>      Why is its structure important?  Couldn’t you just as well limit this
>>      to a single directory full of JAR files?
>>
>> Comments on Debian packaging
>>
>>    - On a Debian machine I tried to create a package for a trivial,
>>      two-module application using the command
>>
>>        $ jpackage -o . --package-type deb -p lib -m org.openjdk.hello -n
>> hello
>>
>>      which gave me the error message
>>
>>         Bundler DEB Installer skipped because of a configuration problem:
>> java.lang.NullPointerException.
>>
>>      (Side note: This message is confusing since the tool is creating a
>>       Debian package, not an “installer.”)
>>
>>    - On a hunch, I specified a main application class:
>>
>>        $ jpackage -o . --package-type deb -p lib -m
>> org.openjdk.hello/org.openjdk.hello.Main -n hello
>>
>>      and that created `hello_1.0-1_amd64.deb`.  It shouldn’t have been
>>      necessary to specify a main class since the main module does have a
>>      `ModuleMainClass` attribute in its module descriptor.
>>
>>    - The resulting package does not depend upon any others, i.e., the
>>      `Depends:` line in its control file is empty.  This can’t possibly be
>>      right, since the embedded JDK depends on many system libraries for
>>      proper operation (`libc`, `libfreetype`, `libpthread`, etc.).
>>
>>    - The resulting package would install into `/opt/hello`, as expected,
>>      but the `/opt/hello/bin` directory would contain not just the `hello`
>>      application launcher but also `hello.desktop`, `hello.png`, and
>>      `libapplauncher.so`.  These aren’t appropriate for a `bin` directory
>>      and should be placed elsewhere, most likely `/opt/hello/lib`.
>>
>>    - The resulting package would install `/opt/hello/app` and
>>      `/opt/hello/runtime` directories.  These are not strictly forbidden
>>      by the Linux FHS [1], but it’d be better to put both of them under
>>      `/opt/hello/lib`, per convention.
>>
>>    - The resulting package does not contain the normal `java` launcher.
>>      It’d be helpful to retain this (in `runtime/bin/java`, not in the
>>      app’s `bin` directory) for diagnostic purposes.  It’s not large.
>>
>>    - The resulting package would install the copyright file into
>>      `/usr/share/doc/hello/copyright`, which is wrong -- a package that
>>      installs into `/opt` should never touch anything under /usr [1].  This
>>      file should be at `/opt/hello/share/doc/copyright`.
>>
>>    - I attempted to install the package on a fresh Ubuntu 18.04 machine:
>>
>>          # dpkg -i hello-1.0.deb
>>          Selecting previously unselected package hello.
>>          (Reading database ... 135670 files and directories currently
>> installed.)
>>          Preparing to unpack hello-1.0.deb ...
>>          Unpacking hello (1.0) ...
>>          Setting up hello (1.0) ...
>>          Adding shortcut to the menu
>>          /var/lib/dpkg/info/hello.postinst: 25:
>> /var/lib/dpkg/info/hello.postinst: xdg-desktop-menu: not found
>>          dpkg: error processing package hello (--install):
>>           installed hello package post-installation script subprocess
>> returned error exit status 127
>>          Errors were encountered while processing:
>>           hello
>>          mr-dev # uname -a
>>          Linux mr-dev 4.15.0-1018-oracle #20-Ubuntu SMP Wed Jul 3 06:46:12
>> UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
>>          mr-dev # cat /etc/lsb-release
>>          DISTRIB_ID=Ubuntu
>>          DISTRIB_RELEASE=18.04
>>          DISTRIB_CODENAME=bionic
>>          DISTRIB_DESCRIPTION="Ubuntu 18.04.3 LTS"
>>          #
>>
>>      Apparently the package should depend upon `xdg-utils`, so that its
>>      post-install script can find `xdg-desktop-menu`.  Even better,
>>      though, would be for this trivial non-graphical application not to
>>      depend upon any desktop utilities, per my comment above.
>>
>>    - Installing the package succeeded despite the above error.  I was
>>      successfully able to run my trivial application.  Yay!
>>
>>    - Then I tried to uninstall it:
>>
>>          mr-dev # dpkg --remove hello
>>          (Reading database ... 135923 files and directories currently
>> installed.)
>>          Removing hello (1.0) ...
>>          Removing shortcut
>>          /var/lib/dpkg/info/hello.prerm: 25:
>> /var/lib/dpkg/info/hello.prerm: xdg-desktop-menu: not found
>>          dpkg: error processing package hello (--remove):
>>           installed hello package pre-removal script subprocess returned
>> error exit status 127
>>          Errors were encountered while processing:
>>           hello
>>          mr-dev #
>>
>>      I installed `xdg-utils` by hand to get `xdg-desktop-menu`, but it still
>>      didn’t work:
>>
>>          mr-dev # dpkg --remove hello
>>          (Reading database ... 136878 files and directories currently
>> installed.)
>>          Removing hello (1.0) ...
>>          Removing shortcut
>>          xdg-desktop-menu: No writable system menu directory found.
>>          dpkg: error processing package hello (--remove):
>>           installed hello package pre-removal script subprocess returned
>> error exit status 3
>>          Errors were encountered while processing:
>>           hello
>>          mr-dev #
>>
>>      I eventually figured out how to create a fake writable system menu
>>      directory and was then able to remove the package.
>>
>>    - The `--linux-deb-copyright` option is confusing.  Its description
>>      should mention that if this option is specified then the `--license`
>>      option is, so far as I can tell, ignored.
>>
>>    - The `--identifier` option appears to have no use for Debian packages.
>>      Perhaps this option should be package-type specific?  Or at least its
>>      description should mention that it’s irrelevant to Debian packages.
>>
>>    - I tried to create a package that would install into the `/usr`
>>      hierarchy by adding `--install-dir /usr` to the above command line.
>>      The resulting package would create a `/usr/hello` directory, with
>>      `app`, `bin`, and `runtime` directories under that.  That’s not
>>      right.  To install an application in the `/usr` hierarchy its command
>>      should go into `/usr/bin`, and libraries and other files should go
>>      into `/usr/lib/$APPNAME`, and documentation and copyright files
>>      should go into `/usr/share/doc/$APPNAME`.
>>
>>    - Many of the above observations could also apply to RPM packages, but
>>      I haven’t checked.
>>
>> Comments on macOS packaging
>>
>>    (Warning: I’m not an expert macOS developer!)
>>
>>    - On a macOS machine (10.13.6) I tried to create a dmg package:
>>
>>        $ jpackage -o . --package-type dmg -p lib -m
>> org.openjdk.hello/org.openjdk.hello.Main -n hello
>>
>>      which gave me the error message
>>
>>        Exec failed with code 1 command [[/usr/bin/SetFile, -c, icnC,
>> /var/folders/mn/8nt00ldx7dqfrv55wk72mgq80000gr/T/jdk.jpackage9024163201922289964/images/hello/.VolumeIcon.icns]
>> in unspecified directory output: xcrun: error: invalid active developer
>> path (/Library/Developer/CommandLineTools), missing xcrun at:
>> /Library/Developer/CommandLineTools/usr/bin/xcrun
>>
>>      although it exited with status 0 and did produce a valid `.dmg` file.
>>      I suppose I’m missing some development tools?  If so then please
>>      document that dependency, and if possible issue a more helpful error
>>      message that tells the user what they need to install.
>>
>>    - It’d be nice if the resulting `.dmg` file, when opened, were to show
>>      an icon for the Applications folder and an arrow pointing to that
>>      from the app icon, so that the user can drag it across.  Almost all
>>      `.dmg` files that I’ve seen do this.
>>
>> - Mark
>>
>>
>> [1]
>> https://www.debian.org/doc/packaging-manuals/fhs/fhs-3.0.html#optAddonApplicationSoftwarePackages
>>