jpackage EA Build 0
sverre.moe at gmail.com
Mon Dec 17 10:31:39 UTC 2018
I have discovered a bug with the jpackage created application image.
It does not pass any --arguments to the application.
The application.cfg contains the arguments, but the native binary does
not pass them to the application.
Den søn. 16. des. 2018 kl. 20:28 skrev Sverre Moe <sverre.moe at gmail.com>:
> Den søn. 16. des. 2018 kl. 19:32 skrev Andy Herrick <andy.herrick at oracle.com>:
> > 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