RFR: JDK-8212780: JEP 343: Packaging Tool Implementation
andy.herrick at oracle.com
Mon Apr 29 21:58:19 UTC 2019
We hope to move JEP 343 to "Proposed to Target" next week, so we would
like expedite the review process as much as possible.
The total change is huge, so I am including the below descriptions of
some of the central and important classes included:
Everything starts with either Main.main() (or
JPackageToolProvider.run() which calls Main.run()), but nothing other
than processing @filename, --help, and --version, is done in Main. The
real work of jpackager is delegated to Arguments.processArguments().
Arguments.processArguments() processes each arg, filling the
DeployParams object with the produced BundleArguments. The DeployParams
are then used to create a BundleParams object.
Arguments.generateBundle() is then called with a Map of the BundleParams
to actually do the work. Argument.generateBundle() then calls the
execute() method of each required Bundler.
A BundlerParamInfo object exists for every parameter (be it a
StandardBundlerParam, or one specific to a given Bundler). These each
contain the function for extracting the id, value type, value, and
default value for the parameter, as well as various methods to convert
to/from Strings. Each is defined as a static final object (again in
either StandardBundlerParam or one of the Bundlers) so it's name can be
used to fetch its value and type. The initial list of parameters is
passed to the Bundler as argument to the execute() method called by
Each platform has a collection of Bundlers, one for an Application
Image, and one for each available installer type, all of which
ultimately implement the Bundler interface. For example, on windows
there is WinAppBundler, WinMsiBundler, and WinExeBundler.
Application Image Bundlers:
The Application Image Bundlers extend AbstractImageBundler which
in turn extends AbstractBundler which implements the Bundler interface.
They will gather the application resources, create the cfg file, and
may call JLinkBundlerHelper.execute() where jlink itself will be called
via the ToolProvider interface to construct the java runtime to include
in the application image. (If a pre defined runtime image is provided it
will be copied in as is, instead of created in JLinkBundlerHelper).
Application Installer Bundlers:
Each Platform dependent installer-type has an associated Bundler
that Extends AbstractBundler (either directly or indirectly). This
Bundler will generally prepare some specific resource template using
fetchResource() or preprocessTextResource (in AbstractBundler) . This
is where user can use --resourceDir option to override the template for
a specific installer type with a templat of his own. The processed
templates become input to the program that generates the installer. An
exception of this is on MacOSX, when the Info.plist must be part of the
application image, so the Info.plist.template is processed when
generating the Application Image Bundle, rather than when processing the
Application Installer Bundler.
All localizable Strings are in jdk/jpackage/internal/resources,
either in HelpResources.properties, MainResources.properties, or the
platform dependent <platform>Resources.properties. The "-ja" and
"-zh_CN" are just copies of the english files at this time, and will be
localized after this code is integrated into the JDK.
Please feel free to post any questions to me while reviewing this code.
On 4/24/2019 8:44 PM, Andy Herrick wrote:
> Please review changes for  which is the implementation bug for
> The webrev at  is the total cumulative webrev of changes for the
> jpackage tool, currently in the JDK-8200758-branch branch of the open
> sandbox repository.
> The webrev at  shows the changes from EA-05 to EA-06.
> The latest EA-6 (build 49) is posted at .
> Please send feedback to core-libs-dev at openjdk.java.net
>  https://bugs.openjdk.java.net/browse/JDK-8200758
>  http://cr.openjdk.java.net/~herrick/8212780/webrev.05-06/
>  http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/
>  http://jdk.java.net/jpackage/
More information about the core-libs-dev