Re: [External] : Re: jpackage usage problems
Hi Hiran, Thank you for providing all the details! I can see two separate issues with jpackage: 1. jpackage reports NPE if it can't figure out the package name from the supplied application image. It should issue a helpful error message instead 2. jpackage fails to populate application image with Java runtime and app specific files when executed in Github but exits with "0" status indicating no error jpackage will successfully build platform-specific packages from any application image by design. It doesn't validate supplied application image to let users create platform specific packages from customized application images. It is no surprise for me that after adding "--name" to jpackage command line it worked. This supplied jpackage a package name that it would normally get from non-empty application image. The major problem in your use case is that jpackage doesn't create correct application image. Instead, it creates only a directory structure of application image, but no files and exits with a "success" status code. This is quite strange. Is there any chance Gradle ignores non-zero exit code from jpackage execution? Can you directly run jpackage command creating application image in the environment where it outputs "empty" application image and check its exit code (please add "--verbose" to jpackage command line to get debug output)? - Alexey On 4/7/2022 3:38 PM, Hiran Chaudhuri wrote: Hello Alex, thank you for coming back. We now have four different cases just for the second build step (appimage->deb). Let me first give you an overview: My Desktop (OpenJDK 16): My Command, Your command Github (OpenJDK 17): My command, Your command On Github I started using OpenJDK11, then switched to 16 and finally to 17. In respect to my build they all seem to behave the same. So I will give the status on all four of the combinations. And btw I use Gradle to trigger command lines which impacts a bit the log output but otherwise should not matter. --My Desktop, my command:-- Starting process 'command 'jpackage''. Working directory: /home/hiran/NetBeansProjects/settlers-installer/app Command: jpackage --app-image build/app-image/SettlersRemake --dest build/distributions --resource-dir build/resources/jpackage Successfully started process 'command 'jpackage'' :app:jpackagePhase2 (Thread[Execution worker for ':' Thread 3,5,main]) completed. Took 12.313 secs. This one runs reliably. I was a bit annoyed that the appdir directory is one level more than for build step 1 (input->appimage) - but maybe that is exactly because I did not specify --name. After all I have a Debian package that I can verify and install. --My Desktop, your command-- Starting process 'command 'jpackage''. Working directory: /home/hiran/NetBeansProjects/settlers-installer/app Command: jpackage --app-image build/app-image/SettlersRemake --dest build/distributions --resource-dir build/resources/jpackage Successfully started process 'command 'jpackage'' :app:jpackagePhase2 (Thread[Execution worker for ':' Thread 3,5,main]) completed. Took 12.313 secs. I added --name as you suggested. It seems I still need to specify the application name on the app-image parameter otherwise the build will fail. A bit strange since build step 1 was run with --dest build/app- image. I have not yet tested the Debian package yet. --Github, my command-- In build step 1 I am running jpackage like so: Starting process 'command 'jpackage''. Working directory: /home/runner/work/settlers-installer/settlers-installer/app Command: jpackage --type app-image --dest build/app-image -i build/jpackage_input/app-0.1.0-SNAPSHOT/lib --main-jar app-0.1.0- SNAPSHOT.jar --main-class settlers.installer.App --name SettlersRemake --app-version 0.1.0-SNAPSHOT --description Settlers 3 remake - see https://urldefense.com/v3/__https://github.com/__;!!ACWV5N9M2RV99hQ!csCrsY1mREmTYmH2eT2wnYjKhiYc2w5-kQMc9GrIoToruZ1Tz4GCYQ3O1a1_JKYyzRfj$ --vendor Hiran --icon build/resources/main/siedler3-helme-logo.png --resource-dir build/resources/jpackage Successfully started process 'command 'jpackage'' :app:jpackagePhase1 (Thread[Daemon worker,5,main]) completed. Took 12.919 secs. There is no error or any suspect message in stdout- Yet I investigated and found out that the app-image directory is almost empty. This is a problem for the second build step. And it is annoying that Gradle garbles the output with other stuff so I hope to have it separated correctly. :app:jpackagePhase2 (Thread[Daemon worker,5,main]) started. Bundler DEB Bundle failed because of java.lang.NullPointerException: Cannot invoke "java.lang.CharSequence.length()" because "this.text" is null Task :app:jpackagePhase2 FAILED * What went wrong: Execution failed for task ':app:jpackagePhase2'. Process 'command 'jpackage'' finished with non-zero exit value 1 Since gradle is not logging the command it invoked I will give you that line from the build file: commandLine 'jpackage', '--app-image',
Re: [External] : Re: jpackage usage problems
On Thu, 2022-04-07 at 19:53 -0400, Alexey Semenyuk wrote: > > I can see two separate issues with jpackage: 1. jpackage reports NPE if it can't figure out the package name > from > the supplied application image. It should issue a helpful error > message > instead > 2. jpackage fails to populate application image with Java runtime > and > app specific files when executed in Github but exits with "0" status > indicating no error > I totally agree these are two separate issues. > > The major problem in your use case is that jpackage doesn't create > correct application image. Instead, it creates only a directory > structure of application image, but no files and exits with a > "success" > status code. This is quite strange. Is there any chance Gradle > ignores > non-zero exit code from jpackage execution? Can you directly run > jpackage command creating application image in the environment where > it > outputs "empty" application image and check its exit code (please > add > "--verbose" to jpackage command line to get debug output)? > > - Alexey > Now this is somewhat puzzling for me: I tried to factor out Gradle by putting the JPackage commands into a separate section of the Github Actions script. So now it is invoked through bash. No wonder, the command triggered by Gradle and the one triggered by bash revealed the same result: A lot of files were missing. I verified this by listing the directories through a 'find'. But then I followed your advice and added --verbose to the JPackage command. And find lists a lot more files now. In case you are interested, check out https://github.com/HiranChaudhuri/settlers-installer/runs/5890636608?check_suite_focus=true So now I believe that --verbose does not only change log output but also impacts app-image creation. BTW, the command used is jpackage --verbose --type app-image --dest app/build/app-image -i app/build/jpackage_input/app-0.1.0-SNAPSHOT/lib --main-jar app-0.1.0- SNAPSHOT.jar --main-class settlers.installer.App --name SettlersRemake --app-version 0.1.0-SNAPSHOT --description 'Settlers 3 remake - see https://github.com/' --vendor Hiran, --icon app/build/resources/main/siedler3-helme-logo.png --resource-dir app/build/resources/jpackage Hiran
Re: [External] : Re: jpackage usage problems
On 4/17/2022 2:22 PM, Hiran Chaudhuri wrote: On Thu, 2022-04-07 at 19:53 -0400, Alexey Semenyuk wrote: I can see two separate issues with jpackage: 1. jpackage reports NPE if it can't figure out the package name from the supplied application image. It should issue a helpful error message instead 2. jpackage fails to populate application image with Java runtime and app specific files when executed in Github but exits with "0" status indicating no error I totally agree these are two separate issues. The major problem in your use case is that jpackage doesn't create correct application image. Instead, it creates only a directory structure of application image, but no files and exits with a "success" status code. This is quite strange. Is there any chance Gradle ignores non-zero exit code from jpackage execution? Can you directly run jpackage command creating application image in the environment where it outputs "empty" application image and check its exit code (please add "--verbose" to jpackage command line to get debug output)? - Alexey Now this is somewhat puzzling for me: I tried to factor out Gradle by putting the JPackage commands into a separate section of the Github Actions script. So now it is invoked through bash. No wonder, the command triggered by Gradle and the one triggered by bash revealed the same result: A lot of files were missing. I verified this by listing the directories through a 'find'. But then I followed your advice and added --verbose to the JPackage command. And find lists a lot more files now. In case you are interested, check out https://urldefense.com/v3/__https://github.com/HiranChaudhuri/settlers-installer/runs/5890636608?check_suite_focus=true__;!!ACWV5N9M2RV99hQ!fMwHRzbnvjiQPsoiuBB1Cnl4RNGxATH4RHnb3Ugy-dlsPTPHLoqOF2uSYcFRkfaSYHQA$ Thank you for sharing. I find this piece of log interesting: --- [19:28:24.553] Command [PID: -1]: jlink --output app/build/app-image/SettlersRemake/lib/runtime --module-path /usr/lib/jvm/temurin-17-jdk-amd64/jmods --add-modules jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,java.xml,jdk.xml.dom,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,java.sql.rowset,jdk.jsobject,jdk.sctp,java.smartcardio,jdk.unsupported,jdk.jlink,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,jdk.incubator.vector,java.sql,java.transaction.xa,java.logging,java.xml.crypto,jdk.jfr,jdk.crypto.cryptoki,jdk.net,jdk.random,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.naming.rmi,jdk.internal.opt,jdk.jconsole,jdk.attach,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.internal.jvmstat,jdk.incubator.foreign,java.instrument,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,jdk.jpackage,java.management.rmi,jdk.naming.dns,jdk.localedata --strip-native-commands --strip-debug --no-man-pages --no-header-files --- It is not quite right that pid of jlink invocation is reported as "-1". jlnk fills runtime directory in app image. Something if off here, invocation of jlink in non-verbose mode fails. In the verbose mode, jpackage saves command lines and output of all external tools it invokes and prints saved data to the console. At least there is a workaround for the issue - add "--verbose" to jpackage command line. I've filed [1] and [2] CRs to track the issues. [1] https://bugs.openjdk.java.net/browse/JDK-8284973 [2] https://bugs.openjdk.java.net/browse/JDK-8284974 - Alexey So now I believe that --verbose does not only change log output but also impacts app-image creation. BTW, the command used is jpackage --verbose --type app-image --dest app/build/app-image -i app/build/jpackage_input/app-0.1.0-SNAPSHOT/lib --main-jar app-0.1.0- SNAPSHOT.jar --main-class settlers.installer.App --name SettlersRemake --app-version 0.1.0-SNAPSHOT --description 'Settlers 3 remake - see https://urldefense.com/v3/__https://github.com/__;!!ACWV5N9M2RV99hQ!fMwHRzbnvjiQPsoiuBB1Cnl4RNGxATH4RHnb3Ugy-dlsPTPHLoqOF2uSYcFRkQh1q_el$ ' --vendor Hiran, --icon app/build/resources/main/siedler3-helme-logo.png --resource-dir app/build/resources/jpackage Hiran
Re: [External] : Re: jpackage usage problems
On Mon, 2022-04-18 at 18:41 -0400, Alexey Semenyuk wrote: > > I've filed [1] and [2] CRs to track the issues. > > [1] https://bugs.openjdk.java.net/browse/JDK-8284973 > [2] https://bugs.openjdk.java.net/browse/JDK-8284974 > > - Alexey Sounds great. Thank you. While we are at improving JPackage, there are a few more items I stumbled over: a) When running jpackage on Linux, a freedesktop.org style starter file is created - but one more line in there would make it a lot more usable: https://stackoverflow.com/questions/70420618/jpackage-linux-creates-insufficient-desktop-file b) The solution is to override resource files. Meanwhile I found out the resource files are templates, and jpackage replaces specific strings in these files. This however is nowhere mentioned in the documentation. c) Running jpackage in two phases as I do (1: create app-image, 2: create final package) I learned that --name has to be specified in both runs. When running jpackage on MacOS however the second run needs the application name postfixed with .app otherwise jpackage won't find the directory it created in the first run. See the logs https://github.com/HiranChaudhuri/settlers-installer/runs/6055932278?check_suite_focus=true and https://github.com/HiranChaudhuri/settlers-installer/runs/6055948346?check_suite_focus=true Hiran
Re: [External] : Re: jpackage usage problems
On 4/18/2022 7:06 PM, Hiran Chaudhuri wrote: On Mon, 2022-04-18 at 18:41 -0400, Alexey Semenyuk wrote: I've filed [1] and [2] CRs to track the issues. [1] https://bugs.openjdk.java.net/browse/JDK-8284973 [2] https://bugs.openjdk.java.net/browse/JDK-8284974 - Alexey Sounds great. Thank you. While we are at improving JPackage, there are a few more items I stumbled over: a) When running jpackage on Linux, a freedesktop.org style starter file is created - but one more line in there would make it a lot more usable: https://urldefense.com/v3/__https://stackoverflow.com/questions/70420618/jpackage-linux-creates-insufficient-desktop-file__;!!ACWV5N9M2RV99hQ!bccLoHcm78kdEbI7iOTUvaVrkbLhw5V7ZjrWS68OXiTaKqbHw-dMGrH3tv8DzhG0W4A9$ b) The solution is to override resource files. Meanwhile I found out the resource files are templates, and jpackage replaces specific strings in these files. This however is nowhere mentioned in the documentation. Must the value of "StartupWMClass" property in .desktop file be synchronized with the value used in the app or it can be any unique value? If the latter, jpackage can create unique value for every launcher based on package and launcher names. Otherwise, if the value must be synchronized with the value used in the app it must be supplied to jpackage. In this case, overriding .desktop template is the way to go. c) Running jpackage in two phases as I do (1: create app-image, 2: create final package) I learned that --name has to be specified in both runs. When running jpackage on MacOS however the second run needs the application name postfixed with .app otherwise jpackage won't find the directory it created in the first run. See the logs https://urldefense.com/v3/__https://github.com/HiranChaudhuri/settlers-installer/runs/6055932278?check_suite_focus=true__;!!ACWV5N9M2RV99hQ!bccLoHcm78kdEbI7iOTUvaVrkbLhw5V7ZjrWS68OXiTaKqbHw-dMGrH3tv8DzplJmV2G$ and https://urldefense.com/v3/__https://github.com/HiranChaudhuri/settlers-installer/runs/6055948346?check_suite_focus=true__;!!ACWV5N9M2RV99hQ!bccLoHcm78kdEbI7iOTUvaVrkbLhw5V7ZjrWS68OXiTaKqbHw-dMGrH3tv8Dzmh3le2h$ --name is optional parameter in both runs. Check out https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/test/jdk/tools/jpackage/share/MultiNameTwoPhaseTest.java testing this feature. I guess you mean "--app-image" parameter, not "--name" parameter. ".app" suffix in app image name on macOS is a legacy jpackage inherited from JavaFX's javapackager. I've filed [1] to track this issue. It may be discarded for the sake of backward compatibility though. [1] https://bugs.openjdk.java.net/browse/JDK-8285265 - Alexey Hiran
Re: [External] : Re: jpackage usage problems
On Wed, 2022-04-20 at 12:38 -0400, Alexey Semenyuk wrote:
>
> On 4/18/2022 7:06 PM, Hiran Chaudhuri wrote:
> > On Mon, 2022-04-18 at 18:41 -0400, Alexey Semenyuk wrote:
> > > I've filed [1] and [2] CRs to track the issues.
> > >
> > > [1] https://bugs.openjdk.java.net/browse/JDK-8284973
> > > [2] https://bugs.openjdk.java.net/browse/JDK-8284974
> > >
> > > - Alexey
> > Sounds great. Thank you.
> >
> > While we are at improving JPackage, there are a few more items I
> > stumbled over:
> >
> > a) When running jpackage on Linux, a freedesktop.org style starter
> > file
> > is created - but one more line in there would make it a lot more
> > usable:
> > https://urldefense.com/v3/__https://stackoverflow.com/questions/70420618/jpackage-linux-creates-insufficient-desktop-file__;!!ACWV5N9M2RV99hQ!bccLoHcm78kdEbI7iOTUvaVrkbLhw5V7ZjrWS68OXiTaKqbHw-dMGrH3tv8DzhG0W4A9$
> >
> > b) The solution is to override resource files. Meanwhile I found
> > out
> > the resource files are templates, and jpackage replaces specific
> > strings in these files. This however is nowhere mentioned in the
> > documentation.
> Must the value of "StartupWMClass" property in .desktop file be
> synchronized with the value used in the app or it can be any unique
> value?
> If the latter, jpackage can create unique value for every launcher
> based
> on package and launcher names.
> Otherwise, if the value must be synchronized with the value used in
> the
> app it must be supplied to jpackage. In this case, overriding
> .desktop
> template is the way to go.
The WMClass of a swing application cannot be configured by the
developer. Yet as much as I saw it is related to the fully qualified
class name that resembles the swing window. So if you use something
like
package org.myproject.mypackage;
public class MyWindow extends JFrame {
...
}
and display an instance of that, it will carry the WMClass parameter as
org-myproject-mypackage-MyWindow
In many cases this class the is the main class at the same time, which
is either specified on the JPackage command line or via the executable
jar's manifest.
I think a reasonable default could be to derive the name from the main
class, with a way to override allowing coverage of exceptional cases.
Most IDEs generate the JFrame classes with a main method. If not
handled you'd force every developer to override resources. If that
becomes the mainstream use case I guess the documentation should be
improved.
>
> > c) Running jpackage in two phases as I do (1: create app-image, 2:
> > create final package) I learned that --name has to be specified in
> > both
> > runs. When running jpackage on MacOS however the second run needs
> > the
> > application name postfixed with .app otherwise jpackage won't find
> > the
> > directory it created in the first run. See the logs
> > https://urldefense.com/v3/__https://github.com/HiranChaudhuri/settlers-installer/runs/6055932278?check_suite_focus=true__;!!ACWV5N9M2RV99hQ!bccLoHcm78kdEbI7iOTUvaVrkbLhw5V7ZjrWS68OXiTaKqbHw-dMGrH3tv8DzplJmV2G$
> > and
> > https://urldefense.com/v3/__https://github.com/HiranChaudhuri/settlers-installer/runs/6055948346?check_suite_focus=true__;!!ACWV5N9M2RV99hQ!bccLoHcm78kdEbI7iOTUvaVrkbLhw5V7ZjrWS68OXiTaKqbHw-dMGrH3tv8Dzmh3le2h$
> --name is optional parameter in both runs. Check out
> https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/test/jdk/tools/jpackage/share/MultiNameTwoPhaseTest.java
> testing this feature.
> I guess you mean "--app-image" parameter, not "--name" parameter.
> ".app"
> suffix in app image name on macOS is a legacy jpackage inherited
> from
> JavaFX's javapackager.
>
> I've filed [1] to track this issue. It may be discarded for the sake
> of
> backward compatibility though.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8285265
>
Oh you are right. I am talking about app-image.
Somehow I'd like to have a more homogenous behaviour across the
platforms. It would allow to keep the build files simple.
This may be difficult to achieve as they impose different requirements.
After all I also stumbled across version numbers on MacOS which are
more restrictive than even on Linux.
Breaking backwards compatibility is a huge pain. Someone will have to
take a decision here.
Thank you for considering. :-)
Hiran
