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
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 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/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 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
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: jpackage usage problems
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://github.com/ --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', 'build/app- image/SettlersRemake', '--dest', 'build', '--resource-dir', 'build/resources/jpackage' --Github, your command-- Since you suggested to add --name on the second step, the first step runs as it was before. And again most files are missing in the output. 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://github.com/ --vendor Hiran --icon build/resources/main/siedler3-helme-logo.png --resource-dir build/resources/jpackage Successfully started process 'command 'jpackage'' :app:jpackagePhase1 (Thread[Execution worker for ':',5,main]) completed. Took 12.672 secs. To verify what files had been created I ran a 'find' afterwards. I had expected the full application, and the JDK runtime. But I only see these files for the appimage: build/app-image build/app-image/SettlersRemake build/app-image/SettlersRemake/lib build/app-image/SettlersRemake/bin build/app-image/SettlersRemake/bin/SettlersRemake With that, the second step is called and outputs this much: Starting process 'command 'jpackage''. Working directory: /home/runner/work/settlers-installer/settlers-installer/app Command: jpackage --app-image build/app-image/SettlersRemake --name SettlersRemake --dest build --resource-dir
Re: jpackage usage problems
Hi Hiran, My apologies for not replying to your previous email. In that particular case the problem seems to be in missing "--name" cli option on the second jpackage command line ($JAVA_HOME/bin/jpackage --app-image build/app-image --verbose --dest build) that is supposed to build .deb package from the app image. Could you please confirm this is the case so I can file more specific description in a CR tracking this issue. Do you have a stack trace for the second NPE? It would help to understand what went wrong. Issue with the Github Runner looks similar to this one [1] [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-March/086656.html - Alexey On 4/7/2022 2:57 AM, Hiran Chaudhuri wrote: Hi there. I have another case where running jpackage emits Bundler DEB Bundle failed because of java.lang.NullPointerException: Cannot invoke "java.lang.CharSequence.length()" because "this.text" is null I have never experienced NullPointerExceptions in other JDK tools. Seems to me JPackage is a new kid on the block. In this case, JPackage is invoked to finish from an existing appimage to the final package. the failure is caused because some important files are missing in appimage. The previous run is even more puzzling for me. It is supposed to create the appimage directory. And while it emits no error message, on my development machine it runs reliably while on the Github Runner it just does not create all files - no error message, no exit code - nothing. Any idea what I could be looking at? Hiran On Mon, 2022-04-04 at 08:49 +0200, Hiran Chaudhuri wrote: Hello Alex, I tried running the same command with the jdk19 you pointed at. As a first, I get this output: $JAVA_HOME/bin/jpackage --version 19-ea With that, I invoked the command as before, and i fairly got the same output. So the behaviour in the latest version has not changed. Two things I'd like to point out: - there is no JPackage version in the output itself so both you and me have to trust the correct one was called - I found out the mistake: I should have used --app-image build/app-image/SettlersRemake but JPackage gave a warning in the beginning and processed all the rest Hiran $JAVA_HOME/bin/jpackage --app-image build/app-image --verbose --dest build [08:41:58.675] Warning: app-image dir not generated by jpackage. [08:41:58.688] Running dpkg [08:41:58.696] Command [PID: 21712]: dpkg --print-architecture [08:41:58.696] Output: amd64 [08:41:58.698] Returned: 0 [08:41:58.702] Running dpkg [08:41:58.719] Command [PID: 21714]: dpkg -s coreutils [08:41:58.719] Output: Package: coreutils Essential: yes Status: install ok installed Priority: required Section: utils Installed-Size: 7196 Maintainer: Ubuntu Developers < ubuntu-devel-disc...@lists.ubuntu.com> Architecture: amd64 Multi-Arch: foreign Version: 8.30-3ubuntu2 Pre-Depends: libacl1 (>= 2.2.23), libattr1 (>= 1:2.4.44), libc6 (>= 2.28), libselinux1 (>= 2.1.13) Description: GNU core utilities This package contains the basic file, shell and text manipulation utilities which are expected to exist on every operating system. . Specifically, this package includes: arch base64 basename cat chcon chgrp chmod chown chroot cksum comm cp csplit cut date dd df dir dircolors dirname du echo env expand expr factor false flock fmt fold groups head hostid id install join link ln logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl nohup nproc numfmt od paste pathchk pinky pr printenv printf ptx pwd readlink realpath rm rmdir runcon sha*sum seq shred sleep sort split stat stty sum sync tac tail tee test timeout touch tr true truncate tsort tty uname unexpand uniq unlink users vdir wc who whoami yes Homepage: http://gnu.org/software/coreutils Original-Maintainer: Michael Stone [08:41:58.719] Returned: 0 [08:41:58.720] Running dpkg-deb [08:41:58.722] Warning: app-image dir not generated by jpackage. [08:41:58.723] Warning: app-image dir not generated by jpackage. [08:41:58.723] java.lang.NullPointerException: Cannot invoke "java.lang.CharSequence.length()" because "this.text" is null at java.base/java.util.regex.Matcher.getTextLength(Matcher.java:1769) at java.base/java.util.regex.Matcher.reset(Matcher.java:415) at java.base/java.util.regex.Matcher.(Matcher.java:252) at java.base/java.util.regex.Pattern.matcher(Pattern.java:1144) at jdk.jpackage/jdk.jpackage.internal.LinuxDebBundler.lambda$static$1(Li nu xDebBundler.java:84) at jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.validate(Linux Pa ckageBundler.java:72) at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments .j ava:688) at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Argumen ts .java:561) at
Re: jpackage usage problems
Hi there. I have another case where running jpackage emits Bundler DEB Bundle failed because of java.lang.NullPointerException: Cannot invoke "java.lang.CharSequence.length()" because "this.text" is null I have never experienced NullPointerExceptions in other JDK tools. Seems to me JPackage is a new kid on the block. In this case, JPackage is invoked to finish from an existing appimage to the final package. the failure is caused because some important files are missing in appimage. The previous run is even more puzzling for me. It is supposed to create the appimage directory. And while it emits no error message, on my development machine it runs reliably while on the Github Runner it just does not create all files - no error message, no exit code - nothing. Any idea what I could be looking at? Hiran On Mon, 2022-04-04 at 08:49 +0200, Hiran Chaudhuri wrote: > Hello Alex, > > I tried running the same command with the jdk19 you pointed at. As a > first, I get this output: > > $JAVA_HOME/bin/jpackage --version > 19-ea > > With that, I invoked the command as before, and i fairly got the same > output. So the behaviour in the latest version has not changed. > > Two things I'd like to point out: > - there is no JPackage version in the output itself so both you and > me > have to trust the correct one was called > - I found out the mistake: I should have used > --app-image build/app-image/SettlersRemake > but JPackage gave a warning in the beginning and processed all the > rest > > Hiran > > > $JAVA_HOME/bin/jpackage --app-image build/app-image --verbose --dest > build > [08:41:58.675] Warning: app-image dir not generated by jpackage. > [08:41:58.688] Running dpkg > [08:41:58.696] Command [PID: 21712]: > dpkg --print-architecture > [08:41:58.696] Output: > amd64 > [08:41:58.698] Returned: 0 > > [08:41:58.702] Running dpkg > [08:41:58.719] Command [PID: 21714]: > dpkg -s coreutils > [08:41:58.719] Output: > Package: coreutils > Essential: yes > Status: install ok installed > Priority: required > Section: utils > Installed-Size: 7196 > Maintainer: Ubuntu Developers < > ubuntu-devel-disc...@lists.ubuntu.com> > Architecture: amd64 > Multi-Arch: foreign > Version: 8.30-3ubuntu2 > Pre-Depends: libacl1 (>= 2.2.23), libattr1 (>= 1:2.4.44), libc6 > (>= > 2.28), libselinux1 (>= 2.1.13) > Description: GNU core utilities > This package contains the basic file, shell and text > manipulation > utilities which are expected to exist on every operating system. > . > Specifically, this package includes: > arch base64 basename cat chcon chgrp chmod chown chroot cksum > comm > cp > csplit cut date dd df dir dircolors dirname du echo env expand > expr > factor false flock fmt fold groups head hostid id install join > link ln > logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl nohup > nproc > numfmt > od paste pathchk pinky pr printenv printf ptx pwd readlink > realpath rm > rmdir runcon sha*sum seq shred sleep sort split stat stty sum > sync > tac > tail tee test timeout touch tr true truncate tsort tty uname > unexpand > uniq unlink users vdir wc who whoami yes > Homepage: http://gnu.org/software/coreutils > Original-Maintainer: Michael Stone > [08:41:58.719] Returned: 0 > > [08:41:58.720] Running dpkg-deb > [08:41:58.722] Warning: app-image dir not generated by jpackage. > [08:41:58.723] Warning: app-image dir not generated by jpackage. > [08:41:58.723] java.lang.NullPointerException: Cannot invoke > "java.lang.CharSequence.length()" because "this.text" is null > at > java.base/java.util.regex.Matcher.getTextLength(Matcher.java:1769) > at java.base/java.util.regex.Matcher.reset(Matcher.java:415) > at java.base/java.util.regex.Matcher.(Matcher.java:252) > at > java.base/java.util.regex.Pattern.matcher(Pattern.java:1144) > at > jdk.jpackage/jdk.jpackage.internal.LinuxDebBundler.lambda$static$1(Li > nu > xDebBundler.java:84) > at > jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.validate(Linux > Pa > ckageBundler.java:72) > at > jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments > .j > ava:688) > at > jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Argumen > ts > .java:561) > at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:91) > at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52) > [08:41:58.725] jdk.jpackage.internal.PackagerException: Bundler DEB > Bundle failed because of java.lang.NullPointerException: Cannot > invoke > "java.lang.CharSequence.length()" because "this.text" is null > at > jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments > .j > ava:710) > at > jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Argumen > ts > .java:561) > at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:91) >
Re: jpackage usage problems
Hello Alex, I tried running the same command with the jdk19 you pointed at. As a first, I get this output: $JAVA_HOME/bin/jpackage --version 19-ea With that, I invoked the command as before, and i fairly got the same output. So the behaviour in the latest version has not changed. Two things I'd like to point out: - there is no JPackage version in the output itself so both you and me have to trust the correct one was called - I found out the mistake: I should have used --app-image build/app-image/SettlersRemake but JPackage gave a warning in the beginning and processed all the rest Hiran $JAVA_HOME/bin/jpackage --app-image build/app-image --verbose --dest build [08:41:58.675] Warning: app-image dir not generated by jpackage. [08:41:58.688] Running dpkg [08:41:58.696] Command [PID: 21712]: dpkg --print-architecture [08:41:58.696] Output: amd64 [08:41:58.698] Returned: 0 [08:41:58.702] Running dpkg [08:41:58.719] Command [PID: 21714]: dpkg -s coreutils [08:41:58.719] Output: Package: coreutils Essential: yes Status: install ok installed Priority: required Section: utils Installed-Size: 7196 Maintainer: Ubuntu Developers < ubuntu-devel-disc...@lists.ubuntu.com> Architecture: amd64 Multi-Arch: foreign Version: 8.30-3ubuntu2 Pre-Depends: libacl1 (>= 2.2.23), libattr1 (>= 1:2.4.44), libc6 (>= 2.28), libselinux1 (>= 2.1.13) Description: GNU core utilities This package contains the basic file, shell and text manipulation utilities which are expected to exist on every operating system. . Specifically, this package includes: arch base64 basename cat chcon chgrp chmod chown chroot cksum comm cp csplit cut date dd df dir dircolors dirname du echo env expand expr factor false flock fmt fold groups head hostid id install join link ln logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl nohup nproc numfmt od paste pathchk pinky pr printenv printf ptx pwd readlink realpath rm rmdir runcon sha*sum seq shred sleep sort split stat stty sum sync tac tail tee test timeout touch tr true truncate tsort tty uname unexpand uniq unlink users vdir wc who whoami yes Homepage: http://gnu.org/software/coreutils Original-Maintainer: Michael Stone [08:41:58.719] Returned: 0 [08:41:58.720] Running dpkg-deb [08:41:58.722] Warning: app-image dir not generated by jpackage. [08:41:58.723] Warning: app-image dir not generated by jpackage. [08:41:58.723] java.lang.NullPointerException: Cannot invoke "java.lang.CharSequence.length()" because "this.text" is null at java.base/java.util.regex.Matcher.getTextLength(Matcher.java:1769) at java.base/java.util.regex.Matcher.reset(Matcher.java:415) at java.base/java.util.regex.Matcher.(Matcher.java:252) at java.base/java.util.regex.Pattern.matcher(Pattern.java:1144) at jdk.jpackage/jdk.jpackage.internal.LinuxDebBundler.lambda$static$1(Linu xDebBundler.java:84) at jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.validate(LinuxPa ckageBundler.java:72) at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.j ava:688) at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments .java:561) at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:91) at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52) [08:41:58.725] jdk.jpackage.internal.PackagerException: Bundler DEB Bundle failed because of java.lang.NullPointerException: Cannot invoke "java.lang.CharSequence.length()" because "this.text" is null at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.j ava:710) at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments .java:561) at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:91) at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52) Caused by: java.lang.NullPointerException: Cannot invoke "java.lang.CharSequence.length()" because "this.text" is null at java.base/java.util.regex.Matcher.getTextLength(Matcher.java:1769) at java.base/java.util.regex.Matcher.reset(Matcher.java:415) at java.base/java.util.regex.Matcher.(Matcher.java:252) at java.base/java.util.regex.Pattern.matcher(Pattern.java:1144) at jdk.jpackage/jdk.jpackage.internal.LinuxDebBundler.lambda$static$1(Linu xDebBundler.java:84) at jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.validate(LinuxPa ckageBundler.java:72) at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.j ava:688) ... 3 more On Fri, 2022-04-01 at 12:37 -0400, Alexey Semenyuk wrote: > Hi Hiran, > > Looks like jpackage fails because of missing package name on the > command > line. > I agree that the error message is not helpful. Can you try one of > jdk19 > EA builds [1] to see if the problem is reproducible? > > [1] https://jdk.java.net/19/ > > -
Re: jpackage usage problems
Hi Hiran, Looks like jpackage fails because of missing package name on the command line. I agree that the error message is not helpful. Can you try one of jdk19 EA builds [1] to see if the problem is reproducible? [1] https://jdk.java.net/19/ - Alexey On 4/1/2022 5:58 AM, Hiran Chaudhuri wrote: Hello there. While I am trying to package my project using jpackage 16.0.1 on Ubuntu 20 LTS I have difficulty in assembling the correct commands. The documentation covers a lot but not everything. For example, it is not clear to me when I have to provide an option - especially since I meanwhile take a two step approach of building the appimage, then tweaking something (that could have done by JPackage directly) and finally building the DEB package. While I believe the documentation is good enough, the error messages presented by JPackage are not. Here is one example. Hopefully you agree that the NullPointerException does not at all tell me what is wrong and what I could improve on. My feeling is that JPackage should do some better error handling and come up with improved messages. Hiran $ jpackage --app-image build/app-image --verbose --dest build [10:34:45.915] Warning: app-image dir not generated by jpackage. [10:34:45.930] Running dpkg [10:34:45.937] Command: dpkg --print-architecture [10:34:45.937] Output: amd64 [10:34:45.939] Returned: 0 [10:34:45.944] Running dpkg [10:34:45.961] Command: dpkg -s coreutils [10:34:45.962] Output: Package: coreutils Essential: yes Status: install ok installed Priority: required Section: utils Installed-Size: 7196 Maintainer: Ubuntu Developers < ubuntu-devel-disc...@lists.ubuntu.com> Architecture: amd64 Multi-Arch: foreign Version: 8.30-3ubuntu2 Pre-Depends: libacl1 (>= 2.2.23), libattr1 (>= 1:2.4.44), libc6 (>= 2.28), libselinux1 (>= 2.1.13) Description: GNU core utilities This package contains the basic file, shell and text manipulation utilities which are expected to exist on every operating system. . Specifically, this package includes: arch base64 basename cat chcon chgrp chmod chown chroot cksum comm cp csplit cut date dd df dir dircolors dirname du echo env expand expr factor false flock fmt fold groups head hostid id install join link ln logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl nohup nproc numfmt od paste pathchk pinky pr printenv printf ptx pwd readlink realpath rm rmdir runcon sha*sum seq shred sleep sort split stat stty sum sync tac tail tee test timeout touch tr true truncate tsort tty uname unexpand uniq unlink users vdir wc who whoami yes Homepage: http://gnu.org/software/coreutils Original-Maintainer: Michael Stone [10:34:45.962] Returned: 0 [10:34:45.963] Running dpkg-deb [10:34:45.965] Warning: app-image dir not generated by jpackage. [10:34:45.967] Warning: app-image dir not generated by jpackage. [10:34:45.967] java.lang.NullPointerException: Cannot invoke "java.lang.CharSequence.length()" because "this.text" is null at java.base/java.util.regex.Matcher.getTextLength(Matcher.java:1769) at java.base/java.util.regex.Matcher.reset(Matcher.java:415) at java.base/java.util.regex.Matcher.(Matcher.java:252) at java.base/java.util.regex.Pattern.matcher(Pattern.java:1134) at jdk.jpackage/jdk.jpackage.internal.LinuxDebBundler.lambda$static$1(Linu xDebBundler.java:83) at jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.validate(LinuxPa ckageBundler.java:72) at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.j ava:663) at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments .java:538) at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:98) at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52) [10:34:45.969] jdk.jpackage.internal.PackagerException: Bundler DEB Bundle failed because of java.lang.NullPointerException: Cannot invoke "java.lang.CharSequence.length()" because "this.text" is null at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.j ava:685) at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments .java:538) at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:98) at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52) Caused by: java.lang.NullPointerException: Cannot invoke "java.lang.CharSequence.length()" because "this.text" is null at java.base/java.util.regex.Matcher.getTextLength(Matcher.java:1769) at java.base/java.util.regex.Matcher.reset(Matcher.java:415) at java.base/java.util.regex.Matcher.(Matcher.java:252) at java.base/java.util.regex.Pattern.matcher(Pattern.java:1134) at jdk.jpackage/jdk.jpackage.internal.LinuxDebBundler.lambda$static$1(Linu xDebBundler.java:83) at
