jpackage EA Build 0

Sverre Moe at
Sun Dec 16 19:28:28 UTC 2018

Den søn. 16. des. 2018 kl. 19:32 skrev Andy Herrick <andy.herrick at>:
> On 12/15/2018 12:44 PM, Andy Herrick wrote:
> While investigating this, I found undocumented functionality left over
> from JavaFXPackager that may be the root of these class-path messages.
> This is both dangerous and powerful, and will require some discussion
> before we either remove it or enhance and document it.
> The functionality is as follows:
> if file ./package/windows/menu.iss exists, ./package/windows/menu.iss
> will be used instead of
> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/template.iss.
> also if ./package/windows/menu.ico exists, it will be used instead of
> config/awt.ico (or instead of javalogo_white_48.ico when no --icon is
> given).
> The bmp used in inno setup can be replaced either by adding
> package/windows/menu-setup-icon.bmp, or by modifying the appropriate
> line in ./package/windows/menu.iss

Yes, this is same as it was for javapackager, but having the
package/<platform> placed on project root is not ideal.
It seem jpackage has changed the directory structure a little, now
using just package instead of package/<platform>.

> As I said we will need to discuss this internally, and we may choose to
> just remove it, but as pointed out above, there are other installer
> parameters (mostly included in the various templates) that a user may
> wish to customize, for which there are no CLI options.

I would not think removing these resource override to be a good idea.
The default templates may not always suffice.

An --app-release would be very useful, specially in addition to the
Release information in the version will work for DEB, but will fail
for RPM since '-' is not allowed.

> Although the current behavior of reading resources from
> "./package/<platform>/<some name substitution of resource name> is not
> really acceptable, adding a CLI option such as --resources-override
> <path> might be possible.

I second an CLI option that would specify where these resources are.

Currently we are preprocessing these resources to replace strings such
as project name, version, etc.
src/main/deploy/package/linux > build/deploy/package/linux


More information about the core-libs-dev mailing list