I did not read the help output well enough where it says "used if no command line arguments are given to the launcher". This means we cannot set any default arguments to the application launcher and support manually entered command line arguments by the user.
Is there a reason for this limitation? Why not support arguments from both the launcher and command line. I created a small test application on GitHub with similar build script we use on our application: https://github.com/DJViking/test-javafx It has one argument --log-level configured with jpackage. ./gradlew createNative ./build/native/test-javafx/bin/test-javafx --other=argument When running this app the --log-level argument are not passed to the application. /Sverre tir. 3. sep. 2019 kl. 12:46 skrev Andy Herrick <andy.herr...@oracle.com>: > I can't reproduce this problem. > > In my manual examples as well as our related automated test cases the > arguments specified by "--arguments <main class arguments>" are being > delivered to the application when it is invoked without command line > arguments. (Note: if there are any arguments given to the command to launch > the app, they override the default arguments, not augment them). > > In the spirit of JDK-8224486 I passed all the following options: > > --arguments --log-level=NONE \ > --arguments --log-level=SOME \ > --arguments --log-level=ALL \ > > to jpackage to package an application that just reported it's arguments, > and it reported all three arguments as expected. > > /Andy > On 9/2/2019 7:14 AM, Sverre Moe wrote: > > I am having problem with arguments not being passed to the application. > The fix JDK-8224486 in this EA release seems to have something to do with > arguments, but it is actually just the JavaOptions. > > The options in ArgOptions in the jpackage cfg does not seem to be passed > to the application > > [ArgOptions] > --log-level=ALL > > This is not passed to the application. When I add it manually on the > command line then it works. > ./build/native/application/bin/application --log-level=ALL > > Is this a known bug with the jpackage? > > /Sverre > > > > tor. 22. aug. 2019 kl. 00:27 skrev Andy Herrick <andy.herr...@oracle.com>: > >> The next EA build of JPackage is available at >> https://jdk.java.net/jpackage/ >> >> This build ( jdk-14-jpackage+1-33 ) (2019/8/20) is the next early access >> release based on JDK-14 >> >> This release contains fixes to the following issues: >> >> JDK-8229788 Error dialog displays with DLL issue when installing >> WinChooserTest application >> JDK-8225447 Revise Debian packaging >> JDK-8213941 Debian linux problems in JavaPackager >> JDK-8229334 jpackage .exe packages cannot be executed due to missing >> DLL >> JDK-8227058 Regressions related to no longer setting user.dir >> JDK-8226599 use code coverage results to remove dead code >> JDK-8226191 jpackager --license-file option broken on windows for >> jdk installers. >> JDK-8215381 Investigate if current implementation of --license-file >> is correct for Debian packages >> JDK-8229138 Add --linux-app-release option for DEB and RPM packages >> JDK-8229791 Code clean up regressions >> JDK-8229786 No output after WinShortcutTest.exe is launched >> JDK-8229750 Fix bad merge of JDK-8215447 patch >> JDK-8215446 JPackageCreateInstallerInstallDirTest fails on OLE7 >> JDK-8215447 Investigate if current implementation of --license-file >> is correct for RPM packages >> JDK-8227172 revert JDK-8225569 on windows >> JDK-8224788 jpackage fails on OS X when using --runtime-image >> JDK-8229252 Add descriptions to Windows jtreg tests >> JDK-8228744 file associations broken on linux. >> JDK-8227312 Remove pkg bundle from DMG image. >> JDK-8228722 jpackage RPM tests fail on some versions of rpmbuild >> JDK-8222778 Packaging Tool (JEP 343) on Linux/AArch64 >> JDK-8224627 Creating installer with --runtime-image on OS X fails >> JDK-8226904 current working directory wrong running jpackage app >> JDK-8224486 Arguments from jpackager cfg file not processed correctly >> JDK-8226835 Command window pops up building exe package >> JDK-8225092 Several jpackage tests failed when run with jcov enabled >> >> /Andy >> >>
