jpackage EA Build 0

[Sverre Moe]

One more thing discovered:
Even though the version is defined in DEB control file, the deb
bundler does not use it for the deb file name.
The RPM bundler does it right. It uses the version and release
specified in the RPM spec file.
application-1.0-deb
application-1.2.3-rc1.rpm

A workaround is to set the --app-version CLI option.

/Sverre

Den man. 17. des. 2018 kl. 11:31 skrev Sverre Moe <sverre.moe at gmail.com>:
>
> 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.
>   [ArgOptions]
>   --laf=nimbus
>   --test1=value1
>   --test2=value2
>
> /Sverre
>
> 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
> > --app-version.
> > 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
> >
> > /Sverre