JDK-8217894 : jpackage CLI syntax changes
  • Type: Bug
  • Component: tools
  • Sub-Component: jpackage
  • Affected Version: internal
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-01-28
  • Updated: 2019-03-22
  • Resolved: 2019-02-12
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
internalFixed
Related Reports
Duplicate :  
JDK-8217789 - Change CLI option "--class" to "--main-class"
Duplicate :  
JDK-8217752 - remove the --limit-modules option
Relates :  
JDK-8217687 - jpackage --help improvements
Relates :  
JDK-8217751 - jpackage messages and failures
Relates :  
JDK-8200758 - JEP 343: Packaging Tool (Incubator)
Relates :  
JDK-8217789 - Change CLI option "--class" to "--main-class"
Relates :  
JDK-8213087 - CSR for JEP 343: Packaging Tool (Incubator)
Relates :  
JDK-8217752 - remove the --limit-modules option
Description
1.) There have been requests to remove the "create-jre-installer <type>" mode, and to fold that into --create-installer mode, using another option to specify that it is a java runtime that is to be installed.

2.) There have been requests to remove the <type> arg to create-installer and create a new option to specify the type of installer.

There may be other syntactical changes to the CLI requested, and they will be added here.

3.) change --class option to --main-class
"--main-class" is clearer and also consistent with what jar tool supports (--main-class option) 

4.) remove the --limit-modules option

5.) request to rename the --force Option
Comments
The above suggestion needs to be considered as a separate enhancement. Even if we split the functionality off into separate tools for each mode, we will need these updated options in one tool or the other (or both). Webrev: http://cr.openjdk.java.net/~herrick/8217894/webrev.01/index.html M5 build: http://java.se.oracle.com:10065/mdash/jobs/aherrick-sandbox-20190205-1531-355258
05-02-2019
Another idea is to have a separate tool to create an installer for a given runtime image or a given app image. jpackage can create an application image. It could also provide a convenient option to first create an application image and then create an installer of the app image (i.e. equivalent to invoking the tools separately).
04-02-2019
The first comment above, and line item 3 in the second comment are withdrawn. The application resources must be contained in a common "input" directory or else there is no way to know how to lay them out in the final image. We will implement only the 5 line items in the description: 1.) remove "create-jre-installer <type>" mode, and add --runtime-installer option. 2.) remove the <type> arg from create-image mode, and add --installer-type option. 3.) change --class option to --main-class 4.) remove the --limit-modules option (At this time we will only remove the cli and leave underlying code) 5.) rename the --force option to --overwrite and improve it's help test.
04-02-2019
added item 3 and 4 in the description to subsume issues JDK-8217752 and JDK-8217789 (closing them as duplicates of this one).
31-01-2019
discussion on 1.) above: We decided to remove the "create-jre-installer" mode and to create runtime installers with just the "create-installer" mode. Above, we proposed to use the option "--runtime-installer" but there were further discussions over email and we need to decide on which option to pursue: 1.1) It was suggested that we require a predefined image. Normal usage would have user creating a jre image (or just modifying an existing jdk image) before passing it to jpackage to create an installer. It would be up to the user what components to add to, or remove from, the image before running jpackage to create the installer(s). a) This can be done by making it an error to use option --runtime-installer without also using --runtime-image option. b) this can be done by giving --runtime-installer an arg that is the image to install. ("--runtime-installer <path to runtime to create installer from>") In either case you could still create an installer for the current version: "$JDK_HOME/bin/jpackage create-installer --runtime-installer --runtime-image $JDK_HOME ..." or "$JDK_HOME/bin/jpackage create-installer --runtime-installer $JDK_HOME ..." 1.2.) If we were to go with (b), since the new arg can be used to create an installer for any payload, it was suggested that the option name not be specific to java runtime. should we use "--image-installer" ? jpackage create-installer --image-installer <image> ...
31-01-2019
The above three changes look good to me.
28-01-2019
After some internal discussion: 1.) we will remove the create-jre-installer mode and replace with using create-installer mode with new option --runtime-installer. 2.) we will remove the <type> arg to create-installer and replace with a new option --installer-type. 3.) we will remove the --files option and modify the --input option to specify a list of paths that can be a list directories and/or files.
28-01-2019
I would like to suggest changing --files to --input-files, and making it no longer relative to the --input dir. you could either specify --input <path list> (and take everything in each path in the list) or --input-files <path list> (and take each listed file.) or both (and take everything in each path and each file). A simplification would be to just replace both --input and --files with --input-files <path list> which would give a list of files and/or directories. For each path in the list that is a directory, take everything in the directory, for each path that is a fill, take that file. I would also suggest both these options be allowed to be repeated, as with other list options.
28-01-2019