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....@gmail.com>: > > Den søn. 16. des. 2018 kl. 19:32 skrev Andy Herrick <andy.herr...@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
