Re: RFR: 8287971: Throw exception for missing values in .jpackage.xml
On Mon, 13 Jun 2022 17:01:48 GMT, Alexander Matveev
wrote:
> - Error will be thrown if app image is generated with another JDK version or
> has malformed .jpackage.xml.
> - Re-fixed as Alexey suggested in https://github.com/openjdk/jdk/pull/9098.
src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_de.properties
line 79:
> 77: warning.no.jdk.modules.found=Warnung: Keine JDK-Module gefunden
> 78:
> 79: error.foreign-app-image=Error: app-image dir ({0}) not generated by
> jpackage. Missing .jpackage.xml.
This error message will be misleading in case app image was generated by
jpackage and adjusted after.
I'd put it as "Missing .jpackage.xml file in app-image dir ({0})."
-
PR: https://git.openjdk.org/jdk19/pull/9
Re: RFR: 8287971: Throw exception for missing values in .jpackage.xml
On Mon, 13 Jun 2022 17:01:48 GMT, Alexander Matveev wrote: > - Error will be thrown if app image is generated with another JDK version or > has malformed .jpackage.xml. > - Re-fixed as Alexey suggested in https://github.com/openjdk/jdk/pull/9098. src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageFile.java line 68: > 66: private final List addLauncherInfos; > 67: private final String signedStr; > 68: private final String appStoreStr; What is the idea of this change? - PR: https://git.openjdk.org/jdk19/pull/9
Re: RFR: 8287971: Throw exception for missing values in .jpackage.xml
On Thu, 9 Jun 2022 01:21:30 GMT, Alexander Matveev wrote: > - Warning will be printed if .jpackage.xml has old version number. > - Error will be thrown if main-class and app-store values are missing from > .jpackage.xml. > - Both main-class and app-store are required values for JDK-8286850 and they > might be missing if user uses app images generated by previous jpackage > version. If some fields of .jpackage.xml are not valid, the entire file must be considered invalid, not only the invalid fields. This is the idea of `AppImageFile.isValid()` method. We do not support backward compatibility for .jpackage.xml for simplicity. We do support only the case when an application image supplied in `--app-image` parameter to jpackage was created by the same jpackage, and not by jpackage from another JDK or from the same JDK but on another platform. I'd discard this fix and create a new one that will: 1. Make `AppImageFile.getVersion()` return the value of `java.version` system property instead of hardcoded "1.0" value. 2. If `AppImageFile.isValid()` returns false, throw exception saying that .jpackage.xml is malformed instead of returning empty AppImageFile instance from `AppImageFile.load()`. - PR: https://git.openjdk.java.net/jdk/pull/9098
Integrated: 8250950: Allow per-user and system wide configuration of a jpackaged app
On Fri, 3 Jun 2022 21:07:47 GMT, Alexey Semenyuk wrote: > 8250950: Allow per-user and system wide configuration of a jpackaged app This pull request has now been integrated. Changeset: c37c8e5d Author: Alexey Semenyuk URL: https://git.openjdk.java.net/jdk/commit/c37c8e5d34905ff2df34a93aa53dd3369e164596 Stats: 599 lines in 15 files changed: 543 ins; 36 del; 20 mod 8250950: Allow per-user and system wide configuration of a jpackaged app Reviewed-by: almatvee - PR: https://git.openjdk.java.net/jdk/pull/9025
Re: RFR: 8250950: Allow per-user and system wide configuration of a jpackaged app
On Fri, 3 Jun 2022 21:07:47 GMT, Alexey Semenyuk wrote: > 8250950: Allow per-user and system wide configuration of a jpackaged app @sashamatveev please resume the review - PR: https://git.openjdk.java.net/jdk/pull/9025
Re: RFR: 8250950: Allow per-user and system wide configuration of a jpackaged app [v2]
> 8250950: Allow per-user and system wide configuration of a jpackaged app Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: Add TKit.createDirectories() method that will delete created nonexistent directories. - Changes: - all: https://git.openjdk.java.net/jdk/pull/9025/files - new: https://git.openjdk.java.net/jdk/pull/9025/files/af2708b4..1f512ff1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=9025=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=9025=00-01 Stats: 38 lines in 2 files changed: 32 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/9025.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/9025/head:pull/9025 PR: https://git.openjdk.java.net/jdk/pull/9025
Re: RFR: 8250950: Allow per-user and system wide configuration of a jpackaged app
On Sat, 4 Jun 2022 01:45:21 GMT, Alexander Matveev wrote:
>> 8250950: Allow per-user and system wide configuration of a jpackaged app
>
> test/jdk/tools/jpackage/share/PerUserCfgTest.java line 174:
>
>> 172: action.accept(cmd);
>> 173: } finally {
>> 174: Files.deleteIfExists(targetCfgFile);
>
> Should we delete parent directory as well?
Correct. We should delete all directories that got created in the preceding
`Files.createDirectories()` call. Will fix this.
-
PR: https://git.openjdk.java.net/jdk/pull/9025
RFR: 8250950: Allow per-user and system wide configuration of a jpackaged app
8250950: Allow per-user and system wide configuration of a jpackaged app - Commit messages: - Trailing white space removed - EOLs converted - Trailing white space removed - 8250950: Allow per-user and system wide configuration of a jpackaged app Changes: https://git.openjdk.java.net/jdk/pull/9025/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=9025=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8250950 Stats: 568 lines in 14 files changed: 512 ins; 36 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/9025.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/9025/head:pull/9025 PR: https://git.openjdk.java.net/jdk/pull/9025
Re: RFR: 8286850: [macos] Add support for signing user provided app image [v3]
On Fri, 3 Jun 2022 02:03:35 GMT, Alexander Matveev wrote: >> - Added support for signing predefined application image. >> - Following command can be used to sign predefined application images: >> jpackage --type app-image --app-image Test.app --mac-sign [additional >> signing options] >> - Main class and if --mac-app-store was specified will be saved in >> .jpackage.xml. Both values are required for signing. Main class is to >> generate default identity and --mac-app-store to do correct signing for App >> Store. >> - Signing is done exactly same as when generating app bundle. Unsigned, >> signed or partially signed app images are supported. App image will be >> completely unsigned before signing. > > Alexander Matveev has updated the pull request incrementally with one > additional commit since the last revision: > > 8286850: [macos] Add support for signing user provided app image [v3] Marked as reviewed by asemenyuk (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8987
Re: RFR: 8286850: [macos] Add support for signing user provided app image
On Thu, 2 Jun 2022 05:17:25 GMT, Alexander Matveev wrote:
> - Added support for signing predefined application image.
> - Following command can be used to sign predefined application images:
> jpackage --type app-image --app-image Test.app --mac-sign [additional signing
> options]
> - Main class and if --mac-app-store was specified will be saved in
> .jpackage.xml. Both values are required for signing. Main class is to
> generate default identity and --mac-app-store to do correct signing for App
> Store.
> - Signing is done exactly same as when generating app bundle. Unsigned,
> signed or partially signed app images are supported. App image will be
> completely unsigned before signing.
Changes requested by asemenyuk (Reviewer).
test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java line 672:
> 670: return this;
> 671: }
> 672:
I guess the idea of this method is to prevent deletion of "." directory in
`execute()` method when `--dest` argument of jpackage command is not set. We
don't want "." directory deleted in any case. So instead of adding
`noCleanupBeforeExec()` that makes sense only if `--dest` argument of jpackage
command is not set, I'd rework the logic of `execute()` method and delete the
output directory only when `--dest` argument is set.
test/jdk/tools/jpackage/macosx/SigningAppImageTwoStepsTest.java line 102:
> 100: .removeArgumentWithValue("--name")
> 101: .removeArgumentWithValue("--main-jar")
> 102: .removeArgumentWithValue("--main-class")
There is no point in calling `JPackageCommand.helloAppImage()` if later all
arguments added by this call get deleted. Simply call JPackageCommand ctor
instead.
test/jdk/tools/jpackage/share/jdk/jpackage/tests/PredefinedAppImageErrorTest.java
line 59:
> 57: * --jpt-run=jdk.jpackage.tests.PredefinedAppImageErrorTest
> 58: *
> --jpt-before-run=jdk.jpackage.test.JPackageCommand.useToolProviderByDefault
> 59: */
There is no need to duplicate the whole jtreg test declaration, it supports
multiple @run comments:
/*
* @test
* @summary Test jpackage output for erroneous input with --type "app-image"
and --app-image
* @library ../../../../helpers
* @build jdk.jpackage.test.*
* @modules jdk.jpackage/jdk.jpackage.internal
* @compile PredefinedAppImageErrorTest.java
*
* @run main/othervm/timeout=360 -Xmx512m jdk.jpackage.test.Main
* --jpt-run=jdk.jpackage.tests.PredefinedAppImageErrorTest
* --jpt-before-run=jdk.jpackage.test.JPackageCommand.useToolProviderByDefault
*
* @run main/othervm/timeout=360 -Xmx512m jdk.jpackage.test.Main
* --jpt-run=jdk.jpackage.tests.PredefinedAppImageErrorTest
* --jpt-before-run=jdk.jpackage.test.JPackageCommand.useExecutableByDefault
*/
test/jdk/tools/jpackage/share/jdk/jpackage/tests/PredefinedAppImageErrorTest.java
line 116:
> 114: Path dummyAppFolder
> 115: = TKit.workDir().resolve("DummyAppImage").toAbsolutePath();
> 116: Files.createDirectory(dummyAppFolder);
Please use `TKit.createTempDirectory()` instead of `Files.createDirectory()`
for the same reason as in `SigningAppImageTwoStepsTest.test()`
-
PR: https://git.openjdk.java.net/jdk/pull/8987
Re: RFR: 8286850: [macos] Add support for signing user provided app image
On Thu, 2 Jun 2022 05:17:25 GMT, Alexander Matveev wrote:
> - Added support for signing predefined application image.
> - Following command can be used to sign predefined application images:
> jpackage --type app-image --app-image Test.app --mac-sign [additional signing
> options]
> - Main class and if --mac-app-store was specified will be saved in
> .jpackage.xml. Both values are required for signing. Main class is to
> generate default identity and --mac-app-store to do correct signing for App
> Store.
> - Signing is done exactly same as when generating app bundle. Unsigned,
> signed or partially signed app images are supported. App image will be
> completely unsigned before signing.
test/jdk/tools/jpackage/macosx/SigningAppImageTwoStepsTest.java line 69:
> 67: SigningCheck.checkCertificates();
> 68:
> 69: Path appimageOutput = TKit.workDir().resolve("appimage");
This should be `TKit.createTempDirectory("appimage")` to allow subsequent
invocations of the test to create a new "appimage" directory if the test work
directory already contains "appimage" directory from the previous test run.
-
PR: https://git.openjdk.java.net/jdk/pull/8987
Re: RFR: 8287125: [macos] Multiple jpackage tests fail/timeout on same host
On Fri, 27 May 2022 03:12:39 GMT, Alexander Matveev wrote: > Looks like regression from JDK-8277493. JDK-8277493 will always un-sign app > image. Un-signing takes time since we enumerating all files and un-signing > binaries one by one. Average increase 2-3 minutes for tests which generates > multiple app images. Fixed by increasing timeout for reported tests. Marked as reviewed by asemenyuk (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8911
Integrated: 8281682: Redundant .ico files in Windows app-image cause unnecessary bloat
On Thu, 19 May 2022 19:13:12 GMT, Alexey Semenyuk wrote: > 8281682: Redundant .ico files in Windows app-image cause unnecessary bloat This pull request has now been integrated. Changeset: 45180633 Author: Alexey Semenyuk URL: https://git.openjdk.java.net/jdk/commit/45180633d34b6cbb679bae0753d9f422e76d6297 Stats: 169 lines in 8 files changed: 150 ins; 6 del; 13 mod 8281682: Redundant .ico files in Windows app-image cause unnecessary bloat Reviewed-by: almatvee - PR: https://git.openjdk.java.net/jdk/pull/8794
RFR: 8281682: Redundant .ico files in Windows app-image cause unnecessary bloat
8281682: Redundant .ico files in Windows app-image cause unnecessary bloat - Commit messages: - Trailing whitespace removed - Drop unused WinIconVerifierException - remove accidentally added space char - jtreg descriptions fixed - 8281682: Redundant .ico files in Windows app-image cause unnecessary bloat Changes: https://git.openjdk.java.net/jdk/pull/8794/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8794=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281682 Stats: 169 lines in 8 files changed: 150 ins; 6 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/8794.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8794/head:pull/8794 PR: https://git.openjdk.java.net/jdk/pull/8794
Re: RFR: 8277493: [REDO] Quarantined jpackage apps are labeled as "damaged" [v2]
On Fri, 13 May 2022 05:06:21 GMT, Alexander Matveev wrote: >> - No changes to code provided by original fix. >> - Added ad hoc signing on macOS aarch64, since macOS aarch64 cannot execute >> unsigned code and code should be at least ad hoc signed. >> - Signing of app bundle produced by AppContentTest.java fails, since it has >> invalid app bundle structure with added files into Content folder. Thus test >> is executed but failure is always expected on macOS aarch64. > > Alexander Matveev has updated the pull request incrementally with one > additional commit since the last revision: > > 8277493: [REDO] Quarantined jpackage apps are labeled as "damaged" [v2] Marked as reviewed by asemenyuk (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8527
Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe
On Thu, 12 May 2022 20:59:53 GMT, Michael Hall wrote: > However, I don't know how the app is supposed to be started without a > launcher... jpackage supplies an alternative launcher that doesn't have plist. - PR: https://git.openjdk.java.net/jdk/pull/8666
Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe [v2]
On Thu, 12 May 2022 04:15:50 GMT, Alexander Matveev wrote: >> - It is not possible to support native JDK commands such as "java" inside >> Mac App Store bundles due to embedded info.plist. Workarounds suggested in >> JDK-8286122 does not seems to be visible. >> - With proposed fix we will enforce "--strip-native-commands" option for >> jlink, so native JDK commands are not included when generating Mac App Store >> bundles. >> - Custom runtime provided via --runtime-image should not contain native >> commands as well, otherwise jpackage will throw error. >> - Added two tests to validate fix. > > Alexander Matveev has updated the pull request incrementally with one > additional commit since the last revision: > > 8286122: [macos]: App bundle cannot upload to Mac App Store due to > info.plist embedded in java exe [v2] Marked as reviewed by asemenyuk (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8666
Re: RFR: 8277493: [REDO] Quarantined jpackage apps are labeled as "damaged"
On Wed, 4 May 2022 03:56:10 GMT, Alexander Matveev wrote: > - No changes to code provided by original fix. > - Added ad hoc signing on macOS aarch64, since macOS aarch64 cannot execute > unsigned code and code should be at least ad hoc signed. > - Signing of app bundle produced by AppContentTest.java fails, since it has > invalid app bundle structure with added files into Content folder. Thus test > is executed but failure is always expected on macOS aarch64. Any chance logic traversing runtime and adjusting the permissions of its files in `unsignAppBundle()` and ` signAdHocAppBundle()` can be moved to a single function instead of being duplicated in both of them? - PR: https://git.openjdk.java.net/jdk/pull/8527
Re: RFR: 8277493: [REDO] Quarantined jpackage apps are labeled as "damaged"
On Wed, 4 May 2022 03:56:10 GMT, Alexander Matveev wrote:
> - No changes to code provided by original fix.
> - Added ad hoc signing on macOS aarch64, since macOS aarch64 cannot execute
> unsigned code and code should be at least ad hoc signed.
> - Signing of app bundle produced by AppContentTest.java fails, since it has
> invalid app bundle structure with added files into Content folder. Thus test
> is executed but failure is always expected on macOS aarch64.
test/jdk/tools/jpackage/macosx/SigningAppImageTest.java line 72:
> 70: @Parameters
> 71: public static List data() {
> 72: return List.of(new Object[][] {{"true"}, {"false"}});
I'd replace use of `@Parameters` with `@Parameter` as follows:
@Test
@Parameter("true")
@Parameter("false")
public static void test(boolean doSign) {...}
-
PR: https://git.openjdk.java.net/jdk/pull/8527
Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe
On Wed, 11 May 2022 21:31:44 GMT, Alexander Matveev
wrote:
> - It is not possible to support native JDK commands such as "java" inside Mac
> App Store bundles due to embedded info.plist. Workarounds suggested in
> JDK-8286122 does not seems to be visible.
> - With proposed fix we will enforce "--strip-native-commands" option for
> jlink, so native JDK commands are not included when generating Mac App Store
> bundles.
> - Custom runtime provided via --runtime-image should not contain native
> commands as well, otherwise jpackage will throw error.
> - Added two tests to validate fix.
test/jdk/tools/jpackage/macosx/MacAppStoreJlinkOptionsTest.java line 48:
> 46:
> 47: @Test
> 48: public static void test() throws Exception {
I'd give some more descriptive names to test functions than `test` and `test2`.
Something like `testWithStripNativeCommands` and
`testWithoutStripNativeCommands` maybe?
-
PR: https://git.openjdk.java.net/jdk/pull/8666
Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe
On Wed, 11 May 2022 21:31:44 GMT, Alexander Matveev
wrote:
> - It is not possible to support native JDK commands such as "java" inside Mac
> App Store bundles due to embedded info.plist. Workarounds suggested in
> JDK-8286122 does not seems to be visible.
> - With proposed fix we will enforce "--strip-native-commands" option for
> jlink, so native JDK commands are not included when generating Mac App Store
> bundles.
> - Custom runtime provided via --runtime-image should not contain native
> commands as well, otherwise jpackage will throw error.
> - Added two tests to validate fix.
Changes requested by asemenyuk (Reviewer).
test/jdk/tools/jpackage/macosx/MacAppStoreRuntimeTest.java line 102:
> 100:
> 101: cmd.execute(1);
> 102: }
@Test
@Parameter("true")
@Parameter("false")
public static void test(boolean stripNativeCommands) throws Exception {
JPackageCommand cmd = JPackageCommand.helloAppImage();
cmd.addArguments("--mac-app-store", "--runtime-image",
getRuntimeImage(stripNativeCommands));
if (stripNativeCommands) {
cmd.executeAndAssertHelloAppImageCreated();
} else {
cmd.execute(1);
}
}
-
PR: https://git.openjdk.java.net/jdk/pull/8666
Integrated: 8282351: jpackage does not work if class file has `$$` in the name on windows
On Mon, 9 May 2022 21:25:37 GMT, Alexey Semenyuk wrote: > 8282351: jpackage does not work if class file has `$$` in the name on windows This pull request has now been integrated. Changeset: 29395534 Author: Alexey Semenyuk URL: https://git.openjdk.java.net/jdk/commit/29395534d9683a802364dc53610dee2b525fb032 Stats: 180 lines in 2 files changed: 178 ins; 0 del; 2 mod 8282351: jpackage does not work if class file has `$$` in the name on windows Reviewed-by: almatvee - PR: https://git.openjdk.java.net/jdk/pull/8613
RFR: 8282351: jpackage does not work if class file has `$$` in the name on windows
8282351: jpackage does not work if class file has `$$` in the name on windows - Commit messages: - Fix regression - 8282351: jpackage does not work if class file has `$$` in the name on windows Changes: https://git.openjdk.java.net/jdk/pull/8613/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8613=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282351 Stats: 180 lines in 2 files changed: 178 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8613.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8613/head:pull/8613 PR: https://git.openjdk.java.net/jdk/pull/8613
Integrated: 8285616: [macos] Incorrect path for launcher-as-service.txt in .cfg file
On Thu, 5 May 2022 20:00:54 GMT, Alexey Semenyuk wrote:
> - Replace `System.getProperty("java.io.tmpdir")` call with hardcoded `/tmp`
> string to get root folder for test files.
> - Fix test cleanup - the test didn't delete test files upon completion
This pull request has now been integrated.
Changeset: 9644a314
Author:Alexey Semenyuk
URL:
https://git.openjdk.java.net/jdk/commit/9644a314cf1c80e43c48474f6f311fc98da597ac
Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod
8285616: [macos] Incorrect path for launcher-as-service.txt in .cfg file
Reviewed-by: almatvee
-
PR: https://git.openjdk.java.net/jdk/pull/8563
RFR: 8285616: [macos] Incorrect path for launcher-as-service.txt in .cfg file
- Replace `System.getProperty("java.io.tmpdir")` call with hardcoded `/tmp`
string to get root folder for test files.
- Fix test cleanup - the test didn't delete test files upon completion
-
Commit messages:
- 8285616: [macos] Incorrect path for launcher-as-service.txt in .cfg file
Changes: https://git.openjdk.java.net/jdk/pull/8563/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8563=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8285616
Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod
Patch: https://git.openjdk.java.net/jdk/pull/8563.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/8563/head:pull/8563
PR: https://git.openjdk.java.net/jdk/pull/8563
Re: Integrated: 8285736: JDK-8236128 causes validate-source failures
On Wed, 27 Apr 2022 16:53:44 GMT, Daniel D. Daugherty wrote: > A trivial fix for JDK-8236128 causes validate-source failures. Marked as reviewed by asemenyuk (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8429
Integrated: JDK-8236128: Allow jpackage create installers for services
On Fri, 11 Mar 2022 23:37:06 GMT, Alexey Semenyuk wrote: > Implementation of [JDK-8275062: "Allow jpackage create installers for > services"](https://bugs.openjdk.java.net/browse/JDK-8275062) > CSR This pull request has now been integrated. Changeset: b675c597 Author:Alexey Semenyuk URL: https://git.openjdk.java.net/jdk/commit/b675c597e3f22af9e75992dab27001b9875af32e Stats: 3116 lines in 64 files changed: 2848 ins; 121 del; 147 mod 8236128: Allow jpackage create installers for services Reviewed-by: almatvee - PR: https://git.openjdk.java.net/jdk/pull/7793
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 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: RFR: JDK-8236128: Allow jpackage create installers for services [v2]
> Implementation of [JDK-8275062: "Allow jpackage create installers for > services"](https://bugs.openjdk.java.net/browse/JDK-8275062) > CSR Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 121 commits: - Merge branch 'master' into JDK-8236128 - Whitespace cleanup - Whitespace cleanup - JDK-8236128: Allow jpackage create installers for services - Sync l10n files. Fix copyright year - Minor formatting fix - Merge fix - Merge fixed - Merge branch 'master' into JDK-8236128 - Merge branch 'JDK-8236128' of https://github.com/alexeysemenyukoracle/jdk into JDK-8236128 - ... and 111 more: https://git.openjdk.java.net/jdk/compare/f4edb59a...1a3d7cf5 - Changes: https://git.openjdk.java.net/jdk/pull/7793/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7793=01 Stats: 3116 lines in 64 files changed: 2848 ins; 121 del; 147 mod Patch: https://git.openjdk.java.net/jdk/pull/7793.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7793/head:pull/7793 PR: https://git.openjdk.java.net/jdk/pull/7793
Re: [External] : Re: jpackage usage problems
ive 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://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[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 build/resources/jpackage Successfully started process 'command 'jpackage'' Warning: app-image dir not generated by jpackage. :app:jpackagePhase2 (Thread[Daemon worker,5,main]) completed. Took 8.099 secs. I am surprised to see success, so my next step would be to evaluate the content of the .deb file. I doubt jpackage would have created all what was missing just now. However this evaluation will have to wait for a week. Hiran On Thu, 2022-04-07 at 14:16 -0400, Alexey Semenyuk wrote: 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: r
Re: jpackage usage problems
s .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) 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(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) ... 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/ - 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(Patter
Integrated: 8284067: jpackage'd launcher reports non-zero exit codes with error prompt
On Thu, 31 Mar 2022 20:08:13 GMT, Alexey Semenyuk wrote: > Add missing `exit(exitCode)` call. > Add relevant unit test. This pull request has now been integrated. Changeset: b9cc3bc1 Author:Alexey Semenyuk URL: https://git.openjdk.java.net/jdk/commit/b9cc3bc1bf61572f2813f057eea7326fd0c2bd14 Stats: 26 lines in 4 files changed: 17 ins; 4 del; 5 mod 8284067: jpackage'd launcher reports non-zero exit codes with error prompt Reviewed-by: almatvee - PR: https://git.openjdk.java.net/jdk/pull/8064
Re: RFR: 8284067: jpackage'd launcher reports non-zero exit codes with error prompt
On Thu, 31 Mar 2022 20:08:13 GMT, Alexey Semenyuk wrote: > Add missing `exit(exitCode)` call. > Add relevant unit test. @sashamatveev please review - PR: https://git.openjdk.java.net/jdk/pull/8064
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
Re: [External] : Re: jpackage Windows support for 4 digits version
Sverre,
exe installers generated by jpackage are just wrappers for msi installers.
Moving workaround you have in Gradle into jpackage will not solve the
problem, but will hide it. This doesn't look appealing.
We need a better solution. I created
https://bugs.openjdk.java.net/browse/JDK-8283707 CR to track your request.
- Alexey
On 3/25/2022 3:21 AM, Sverre Moe wrote:
Hi,
I was hoping something could be done to allow 4 fields in the version
on Windows when using jpackage.
Even though Windows will ignore the fourth component when installing,
that is ok, but if we could build just build an EXE with 4 fields
version. If by some configuration with jpackage, or the WiX Toolset it
uses to build an EXE.
I wanted to avoid having to configure an exception for Windows in
Gradle like this
jpackage {
if (isWindows) {
appVersion = applicationVersion.substring(0,
applicationVersion.lastIndexOf("."))
} else {
appVersion = applicationVersion
}
}
I found someone who made a solution to allow a version with 4 fields
on Windows.
https://github.com/hvandrie/msiCAFindRelatedProductsEx
However that would be a much more complex workaround than the one above.
/Sverre
fre. 25. mar. 2022 kl. 08:00 skrev David Holmes :
On 25/03/2022 5:14 am, Alexey Semenyuk wrote:
> Hi Sverre,
>
> Oh, I misunderstood the problem. I though the issue was with
parsing WiX
> version string, but the problem is that jpackage doesn't like
the value
> of --version cli parameter.
> On windows this value should satisfy constrains of MSI
ProductVersion
> property [1]:
> The format of the string is as follows:
> major.minor.build
> The first field is the major version and has a maximum value of
255. The
> second field is the minor version and has a maximum value of
255. The
> third field is called the build version or the update version
and has a
> maximum value of 65,535.
It also states:
"Note that Windows Installer uses only the first three fields of the
product version. If you include a fourth field in your product
version,
the installer ignores the fourth field."
So I think ignoring that fourth field is what is being requested.
Cheers,
David
> If not doing validation early, wix candle will fail later. This is
> platform limitation, not the limitation of jpackage.
>
> [1]
https://msdn.microsoft.com/en-us/library/aa370859%28v=VS.85%29.aspx
>
> - Alexey
>
> On 3/24/2022 2:04 PM, Sverre Moe wrote:
>> Hi,
>>
>> This has been attempted on Java 15, Java 16 and the latest Java 17.
>>
>> This is the output from Java 17
>>
>> 14:46:49
>>
C:\cygwin64\home\build\jenkins-test\workspace\our-awesome-project_sverre_SF-99>gradlew.bat
>> --no-daemon --version
>> 14:46:51
>> 14:46:51
>> 14:46:51 Gradle 7.3.3
>> 14:46:51
>> 14:46:51
>> 14:46:51 Build time: 2021-12-22 12:37:54 UTC
>> 14:46:51 Revision: 6f556c80f945dc54b50e0be633da6c62dbe8dc71
>> 14:46:51
>> 14:46:51 Kotlin: 1.5.31
>> 14:46:51 Groovy: 3.0.9
>> 14:46:51 Ant: Apache Ant(TM) version 1.10.11 compiled on
>> July 10 2021
>> 14:46:51 JVM: 17.0.2 (Eclipse Adoptium 17.0.2+8)
>> 14:46:51 OS: Windows 10 10.0 amd64
>>
>>
>> 14:46:53
>>
C:\cygwin64\home\build\jenkins-test\workspace\our-awesome-project_sverre_SF-99>gradlew.bat
>> --no-daemon --stacktrace --refresh-dependencies -Pheadless
>> createPackage
>> 14:48:51 > Task :jpackage
>> 14:48:51 [14:49:12.348] Running candle.exe
>> 14:48:51 [14:49:12.386] Running C:\Program Files (x86)\WiX
Toolset
>> v3.11\bin\candle.exe
>> 14:48:51 [14:49:12.762] Running light.exe
>> 14:48:51 [14:49:12.773] Running C:\Program Files (x86)\WiX
Toolset
>> v3.11\bin\light.exe
>> 14:48:51 [14:49:13.207] Detected [candle.exe] version
[3.11.2.4516].
>> 14:48:51 [14:49:13.208] Detected [light.exe] version
[3.11.2.4516].
>> 14:48:51 [14:49:13.210] WiX 3.11.2.4516 detected. Enabling
advanced
>> cleanup action.
>> 14:48:51 [14:49:13.211] jdk.jpackage.internal.ConfigException:
>> Version sting may have between 1 and 3 components: 1, 1.2, 1.2.3.
>> 14:48:51 at
>>
jdk.jpackage/jdk.jpack
Re: [External] : Re: jpackage Windows support for 4 digits version
4:48:51 > Task :jpackage FAILED 14:48:51 14:48:51 FAILURE: Build failed with an exception. 14:48:51 14:48:51 * What went wrong: 14:48:51 Execution failed for task ':jpackage'. 14:48:51 > Process 'command 'C:\Program Files\Eclipse Adoptium\jdk-17.0.2.8-hotspot/bin/jpackage.exe'' finished with non-zero exit tor. 24. mar. 2022 kl. 17:39 skrev Alexey Semenyuk : Hi Sverre, The output comes from quite old jpackage (jdk15, I guess). Please try jpackage from the newer jdk (the latest one would be the best option). They don't have this issue. - Alexey On 3/23/2022 10:01 AM, Sverre Moe wrote: > Could jpackage instruct WiX when building a native application on Windows, > to support 4 digits in the version? > > 14:41:18 Detected [light.exe] version [3.11.2.4516]. > 14:41:18 Detected [candle.exe] version [3.11.2.4516]. > 14:41:18 WiX 3.11.2.4516 detected. Enabling advanced cleanup action. > 14:41:18 Version sting may have up to 3 components - major.minor.build . > 14:41:18 jdk.incubator.jpackage.internal.ConfigException: Version string > is not compatible with MSI rules [1.10.3.1] > 14:41:18 at > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.WinMsiBundler.validate(WinMsiBundler.java:256) > 14:41:18 at > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.WinExeBundler.validate(WinExeBundler.java:99) > 14:41:18 at > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:640) > 14:41:18 at > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.processArguments(Arguments.java:514) > 14:41:18 at > jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.execute(Main.java:97) > 14:41:18 at > jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.main(Main.java:51) > 14:41:18 jdk.incubator.jpackage.internal.PackagerException: Bundler EXE > Installer Package skipped because of a configuration problem: Version > string is not compatible with MSI rules [1.10.3.1] > 14:41:18 Advice to fix: Set the bundler argument "win.msi.productVersion" > according to these rules: > https://msdn.microsoft.com/en-us/library/aa370859%28v=VS.85%29.aspx <https://urldefense.com/v3/__https://msdn.microsoft.com/en-us/library/aa370859*28v=VS.85*29.aspx__;JSU!!ACWV5N9M2RV99hQ!YstqoaSBaYrCTH11faRgBaN3Ty0NnlGP-1Q-IPI8DaDXTXeHNu1-VkCoS5UeOYqO3iFS$> . > 14:41:18 at > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:653) > 14:41:18 at > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.processArguments(Arguments.java:514) > 14:41:18 at > jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.execute(Main.java:97) > 14:41:18 at > jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.main(Main.java:51) > 14:41:18 Caused by: jdk.incubator.jpackage.internal.ConfigException: > Version string is not compatible with MSI rules [1.10.3.1] > 14:41:18 at > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.WinMsiBundler.validate(WinMsiBundler.java:256) > 14:41:18 at > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.WinExeBundler.validate(WinExeBundler.java:99) > 14:41:18 at > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:640) > 14:41:18 ... 3 more > > Perhaps something like this solution could be incorporated with the > JPackage tool. > https://github.com/hvandrie/msiCAFindRelatedProductsEx <https://urldefense.com/v3/__https://github.com/hvandrie/msiCAFindRelatedProductsEx__;!!ACWV5N9M2RV99hQ!YstqoaSBaYrCTH11faRgBaN3Ty0NnlGP-1Q-IPI8DaDXTXeHNu1-VkCoS5UeOR0PTqUZ$> > jpackage --windows-version-components=4
Re: jpackage Windows support for 4 digits version
Hi Sverre, The output comes from quite old jpackage (jdk15, I guess). Please try jpackage from the newer jdk (the latest one would be the best option). They don't have this issue. - Alexey On 3/23/2022 10:01 AM, Sverre Moe wrote: Could jpackage instruct WiX when building a native application on Windows, to support 4 digits in the version? 14:41:18 Detected [light.exe] version [3.11.2.4516]. 14:41:18 Detected [candle.exe] version [3.11.2.4516]. 14:41:18 WiX 3.11.2.4516 detected. Enabling advanced cleanup action. 14:41:18 Version sting may have up to 3 components - major.minor.build . 14:41:18 jdk.incubator.jpackage.internal.ConfigException: Version string is not compatible with MSI rules [1.10.3.1] 14:41:18 at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.WinMsiBundler.validate(WinMsiBundler.java:256) 14:41:18 at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.WinExeBundler.validate(WinExeBundler.java:99) 14:41:18 at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:640) 14:41:18 at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.processArguments(Arguments.java:514) 14:41:18 at jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.execute(Main.java:97) 14:41:18 at jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.main(Main.java:51) 14:41:18 jdk.incubator.jpackage.internal.PackagerException: Bundler EXE Installer Package skipped because of a configuration problem: Version string is not compatible with MSI rules [1.10.3.1] 14:41:18 Advice to fix: Set the bundler argument "win.msi.productVersion" according to these rules: https://msdn.microsoft.com/en-us/library/aa370859%28v=VS.85%29.aspx . 14:41:18 at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:653) 14:41:18 at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.processArguments(Arguments.java:514) 14:41:18 at jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.execute(Main.java:97) 14:41:18 at jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.main(Main.java:51) 14:41:18 Caused by: jdk.incubator.jpackage.internal.ConfigException: Version string is not compatible with MSI rules [1.10.3.1] 14:41:18 at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.WinMsiBundler.validate(WinMsiBundler.java:256) 14:41:18 at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.WinExeBundler.validate(WinExeBundler.java:99) 14:41:18 at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:640) 14:41:18 ... 3 more Perhaps something like this solution could be incorporated with the JPackage tool. https://github.com/hvandrie/msiCAFindRelatedProductsEx jpackage --windows-version-components=4
RFR: JDK-8236128: Allow jpackage create installers for services
Implementation of [JDK-8275062: "Allow jpackage create installers for services"](https://bugs.openjdk.java.net/browse/JDK-8275062) CSR - Commit messages: - Whitespace cleanup - Whitespace cleanup - JDK-8236128: Allow jpackage create installers for services - Sync l10n files. Fix copyright year - Minor formatting fix - Merge fix - Merge fixed - Merge branch 'master' into JDK-8236128 - Merge branch 'JDK-8236128' of https://github.com/alexeysemenyukoracle/jdk into JDK-8236128 - Bugfix - ... and 110 more: https://git.openjdk.java.net/jdk/compare/cd234f5d...0ff8e9aa Changes: https://git.openjdk.java.net/jdk/pull/7793/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7793=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8236128 Stats: 2769 lines in 64 files changed: 2508 ins; 121 del; 140 mod Patch: https://git.openjdk.java.net/jdk/pull/7793.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7793/head:pull/7793 PR: https://git.openjdk.java.net/jdk/pull/7793
Re: RFR: 8279995: jpackage --add-launcher option should allow overriding description [v6]
On Fri, 25 Feb 2022 01:27:52 GMT, Alexander Matveev wrote: >> Added ability to override description for additional launchers via >> "description" property. > > Alexander Matveev has updated the pull request incrementally with one > additional commit since the last revision: > > 8279995: jpackage --add-launcher option should allow overriding description > [v5] Marked as reviewed by asemenyuk (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7399
Re: RFR: 8279995: jpackage --add-launcher option should allow overriding description [v4]
On Thu, 17 Feb 2022 06:54:33 GMT, Alexander Matveev
wrote:
>> Added ability to override description for additional launchers via
>> "description" property.
>
> Alexander Matveev has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8279995: jpackage --add-launcher option should allow overriding description
> [v4]
test/jdk/tools/jpackage/helpers/jdk/jpackage/test/WindowsHelper.java line 165:
> 163:
> 164: return description;
> 165: }
How about this:
public static String getExecutableDesciption(Path pathToExeFile) {
Executor exec = Executor.of("powershell",
"-NoLogo",
"-NoProfile",
"-Command",
"(Get-Item \\""
+ pathToExeFile.toAbsolutePath()
+ "\\").VersionInfo | select FileDescription");
var lineIt = exec.dumpOutput().executeAndGetOutput().iterator();
while (lineIt.hasNext()) {
var line = lineIt.next();
if (line.trim().equals("FileDescription")) {
// Skip "---" and move to the description value
lineIt.next();
var description = lineIt.next().trim();
if (lineIt.hasNext()) {
throw new RuntimeException("Unexpected input");
}
return description;
}
}
throw new RuntimeException(String.format(
"Failed to get file description of [%s]", pathToExeFile));
}
Added `Executor.dumpOutput()` call to save the output of powershell command in
the test log for easier debugging.
No null initialized `description` variable. No iteration over the list using
the index. Check for the end of the output.
-
PR: https://git.openjdk.java.net/jdk/pull/7399
Re: JDK-17: Wndows jpackage destination directory not writable
Hi Sverre, Interesting, I don't see changes in jpackage code related to the issue. In particular jdk.jpackage.internal.IOUtils.writableOutputDir() function is the same in JDK14, JDK17, and mainline. - Alexey On 2/18/2022 8:31 AM, Sverre Moe wrote: I executed our JDK11 docker image, which works fine with JDK11 and JDK14 (for jpackage support). Then I installed the JDK17 MSI package, changed JAVA_HOME and PATH. Building our application now with JDK17 it still cannot write to the "build/native" jpackage output directory. Leads me to conclude something has changed in jpackage between JDK14 and JDK17. I modified my gradle configuration, to use jpackage from JDK14 when packaging my JDK17 built application. It works using JDK14 jpackage to package our JDK17 application. Using the JDK17 jpackage directly in Windows works fine. It is only in the Docker container that it does not work. /Sverre tir. 5. okt. 2021 kl. 11:55 skrev Sverre Moe: I ran cacls after the failed jpackage. C:\temp\my-javafx-application>cacls build C:\temp\my-javafx-application\build F CREATOR OWNER:(OI)(CI)(IO)F R CREATOR GROUP:(OI)(CI)(IO)R Everyone:(OI)(CI)R C:\temp\my-javafx-application>cacls build\native C:\temp\my-javafx-application\build\native F CREATOR OWNER:(OI)(CI)(IO)F R CREATOR GROUP:(OI)(CI)(IO)R Everyone:(OI)(CI)R As cacls was deprecated it suggested to use icacls instead: C:\temp\my-javafx-application>icacls build build S-1-5-21-406077803-2019195645-689573112-1003:(I)(F) CREATOR OWNER:(I)(OI)(CI)(IO)(F) S-1-5-21-406077803-2019195645-689573112-513:(I)(RX) CREATOR GROUP:(I)(OI)(CI)(IO)(RX) Everyone:(I)(OI)(CI)(RX) Successfully processed 1 files; Failed processing 0 files C:\temp\my-javafx-application>icacls build\native build\native S-1-5-83-1-1537791174-1084404783-2478187907-2577323605:(I)(F) CREATOR OWNER:(I)(OI)(CI)(IO)(F) S-1-5-83-0:(I)(RX) CREATOR GROUP:(I)(OI)(CI)(IO)(RX) Everyone:(I)(OI)(CI)(RX) Successfully processed 1 files; Failed processing 0 files Running attrib on the workspace, and build dirs: C:\Temp\my-javafx-application>attrib AC:\Temp\my-javafx-application\.description AC:\Temp\my-javafx-application\.gitignore AC:\Temp\my-javafx-application\build.gradle AC:\Temp\my-javafx-application\gradle.properties AC:\Temp\my-javafx-application\gradlew AC:\Temp\my-javafx-application\gradlew.bat AC:\Temp\my-javafx-application\Jenkinsfile AC:\Temp\my-javafx-application\packager.gradle AC:\Temp\my-javafx-application\README.adoc AC:\Temp\my-javafx-application\settings.gradle AC:\Temp\my-javafx-application\spotless.gradle C:\Temp\my-javafx-application>attrib build C:\Temp\my-javafx-application\build C:\Temp\meos-dashboard>attrib build\native C:\Temp\my-javafx-application\build\native /Sverre tir. 5. okt. 2021 kl. 10:41 skrev Alan Bateman: On 05/10/2021 08:54, Sverre Moe wrote: With JDK 17, jpackage fails to write to the destination directory on Windows. It worked fine with JDK 11 (with jpackage from JDK14) and Docker. Only happens on Windows docker. Running directly on WIndows it works with JDK 17. What has changed with jpackage that it no longer can write to the destination directory when running in Docker? Is it a regression/bug with jpackage? I don't know what has changed in jpackage, maybe it didn't check for write access previously. However, the error you are seeing suggests there may be a lower-level issue, maybe a driver issue. It would be useful if you could print out the DACL (using cacls is okay) and the DOS attributes. -Alan
Integrated: 8282007: Assorted enhancements to jpackage testing framework
On Wed, 16 Feb 2022 20:06:09 GMT, Alexey Semenyuk wrote: > 8282007: Assorted enhancements to jpackage testing framework This pull request has now been integrated. Changeset: cd234f5d Author: Alexey Semenyuk URL: https://git.openjdk.java.net/jdk/commit/cd234f5dbebd18ebf0c78dfdf533318cdc627971 Stats: 742 lines in 17 files changed: 416 ins; 180 del; 146 mod 8282007: Assorted enhancements to jpackage testing framework Reviewed-by: almatvee - PR: https://git.openjdk.java.net/jdk/pull/7502
Re: RFR: 8282007: Assorted enhancements to jpackage testing framework [v2]
On Wed, 16 Feb 2022 23:53:44 GMT, Alexander Matveev wrote: >> Alexey Semenyuk has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Don't fail if requested to uninstall not installed Debian package > > test/jdk/tools/jpackage/helpers/jdk/jpackage/test/CfgFile.java line 2: > >> 1: /* >> 2: * Copyright (c) 2019, 2022 Oracle and/or its affiliates. All rights >> reserved. > > Missing ",". Fixed! > test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TKit.java line 2: > >> 1: /* >> 2: * Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved. > > Do you know why 2021 is removed? By accident. Restored and changed to 2022 - PR: https://git.openjdk.java.net/jdk/pull/7502
Re: RFR: 8282007: Assorted enhancements to jpackage testing framework [v3]
> 8282007: Assorted enhancements to jpackage testing framework Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: Copyright years fixed - Changes: - all: https://git.openjdk.java.net/jdk/pull/7502/files - new: https://git.openjdk.java.net/jdk/pull/7502/files/8ce156d9..c890c8a4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7502=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7502=01-02 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7502.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7502/head:pull/7502 PR: https://git.openjdk.java.net/jdk/pull/7502
Re: RFR: 8282007: Assorted enhancements to jpackage testing framework [v2]
> 8282007: Assorted enhancements to jpackage testing framework Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: Don't fail if requested to uninstall not installed Debian package - Changes: - all: https://git.openjdk.java.net/jdk/pull/7502/files - new: https://git.openjdk.java.net/jdk/pull/7502/files/895997ac..8ce156d9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7502=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7502=00-01 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7502.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7502/head:pull/7502 PR: https://git.openjdk.java.net/jdk/pull/7502
Integrated: 8282011: test/jdk/tools/jpackage/windows/WinL10nTest.java test fails if light.exe is not in %PATH%
On Wed, 16 Feb 2022 17:52:43 GMT, Alexey Semenyuk wrote: > 8282011: test/jdk/tools/jpackage/windows/WinL10nTest.java test fails if > light.exe is not in %PATH% This pull request has now been integrated. Changeset: 0b00ce17 Author:Alexey Semenyuk URL: https://git.openjdk.java.net/jdk/commit/0b00ce17cd6b530d9394e79ac8b07208cd4b92f5 Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod 8282011: test/jdk/tools/jpackage/windows/WinL10nTest.java test fails if light.exe is not in %PATH% Reviewed-by: almatvee - PR: https://git.openjdk.java.net/jdk/pull/7500
RFR: 8282007: Assorted enhancements to jpackage testing framework
8282007: Assorted enhancements to jpackage testing framework - Commit messages: - Trailing whitespace removed - 8282007: Assorted enhancements to jpackage testing framework - macOS bugix - Don't use TKit.assertZZZ to validate test setup correctness. Throw exception instead. - Assorted fixes and enhancements to jpackage testing framework Changes: https://git.openjdk.java.net/jdk/pull/7502/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7502=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282007 Stats: 738 lines in 17 files changed: 413 ins; 180 del; 145 mod Patch: https://git.openjdk.java.net/jdk/pull/7502.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7502/head:pull/7502 PR: https://git.openjdk.java.net/jdk/pull/7502
RFR: 8282011: test/jdk/tools/jpackage/windows/WinL10nTest.java test fails if light.exe is not in %PATH%
8282011: test/jdk/tools/jpackage/windows/WinL10nTest.java test fails if light.exe is not in %PATH% - Commit messages: - 8282011: test/jdk/tools/jpackage/windows/WinL10nTest.java test fails locally Changes: https://git.openjdk.java.net/jdk/pull/7500/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7500=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282011 Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7500.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7500/head:pull/7500 PR: https://git.openjdk.java.net/jdk/pull/7500
Integrated: 8281874: Can't unpack msi installers from test/jdk/tools/jpackage/windows/test/jdk/tools/jpackage/windows/WinShortcutPromptTest.java test
On Tue, 15 Feb 2022 22:56:35 GMT, Alexey Semenyuk wrote: > 8281874: Can't unpack msi installers from > test/jdk/tools/jpackage/windows/test/jdk/tools/jpackage/windows/WinShortcutPromptTest.java > test This pull request has now been integrated. Changeset: 81645521 Author: Alexey Semenyuk URL: https://git.openjdk.java.net/jdk/commit/81645521c81c7363d199e5051d51043146058a91 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8281874: Can't unpack msi installers from test/jdk/tools/jpackage/windows/test/jdk/tools/jpackage/windows/WinShortcutPromptTest.java test Reviewed-by: almatvee - PR: https://git.openjdk.java.net/jdk/pull/7484
Integrated: 8281170: Test jdk/tools/jpackage/windows/WinInstallerIconTest always fails on Windows 11
On Tue, 15 Feb 2022 17:44:24 GMT, Alexey Semenyuk wrote: > Code clean up. Remove obsolete comments, unused imports, and unneeded jtreg > test parameter. > Fix the code to handle the case when installers are not created and there is > nothing to verify in the test. This pull request has now been integrated. Changeset: bb4dece2 Author:Alexey Semenyuk URL: https://git.openjdk.java.net/jdk/commit/bb4dece246a56f2b225089c331e9f3d092dfbfa1 Stats: 46 lines in 1 file changed: 12 ins; 19 del; 15 mod 8281170: Test jdk/tools/jpackage/windows/WinInstallerIconTest always fails on Windows 11 Reviewed-by: almatvee - PR: https://git.openjdk.java.net/jdk/pull/7481
RFR: 8281874: Can't unpack msi installers from test/jdk/tools/jpackage/windows/test/jdk/tools/jpackage/windows/WinShortcutPromptTest.java test
8281874: Can't unpack msi installers from test/jdk/tools/jpackage/windows/test/jdk/tools/jpackage/windows/WinShortcutPromptTest.java test - Commit messages: - 8281874: Can't unpack msi installers from test/jdk/tools/jpackage/windows/test/jdk/tools/jpackage/windows/WinShortcutPromptTest.java test Changes: https://git.openjdk.java.net/jdk/pull/7484/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7484=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281874 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7484.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7484/head:pull/7484 PR: https://git.openjdk.java.net/jdk/pull/7484
RFR: 8281170: Test jdk/tools/jpackage/windows/WinInstallerIconTest always fails on Windows 11
Code clean up. Remove obsolete comments, unused imports, and unneeded jtreg test parameter. Fix the code to handle the case when installers are not created and there is nothing to verify in the test. - Commit messages: - 8281170: Test jdk/tools/jpackage/windows/WinInstallerIconTest always fails on Windows 11 Changes: https://git.openjdk.java.net/jdk/pull/7481/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7481=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281170 Stats: 46 lines in 1 file changed: 12 ins; 19 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/7481.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7481/head:pull/7481 PR: https://git.openjdk.java.net/jdk/pull/7481
Re: RFR: 8279995: jpackage --add-launcher option should allow overriding description [v3]
On Mon, 14 Feb 2022 23:56:43 GMT, Alexander Matveev wrote: >> Added ability to override description for additional launchers via >> "description" property. > > Alexander Matveev has updated the pull request incrementally with one > additional commit since the last revision: > > 8279995: jpackage --add-launcher option should allow overriding description > [v3] test/jdk/tools/jpackage/helpers/jdk/jpackage/test/WindowsHelper.java line 159: > 157: } > 158: > 159: TKit.assertNotNull(description, "Failed to get file > description"); Failure to get the executable's description through powersehll script is not an issue of a test case being executed. This is the testing framework issue. Throwing RuntimeException with the message containing file path will be the appropriate error handling. Having a file name in the exception message will help to localize the issue. - PR: https://git.openjdk.java.net/jdk/pull/7399
Re: RFR: 8279995: jpackage --add-launcher option should allow overriding description [v3]
On Mon, 14 Feb 2022 23:56:43 GMT, Alexander Matveev wrote: >> Added ability to override description for additional launchers via >> "description" property. > > Alexander Matveev has updated the pull request incrementally with one > additional commit since the last revision: > > 8279995: jpackage --add-launcher option should allow overriding description > [v3] test/jdk/tools/jpackage/helpers/jdk/jpackage/test/AdditionalLauncher.java line 265: > 263: WindowsHelper.getExecutableDesciption(launcherPath); > 264: TKit.assertEquals(expectedDescription, actualDescription, > 265: "Invalid file description"); The message should be the name of an action taken, not the error description. The testing framework will build the error message itself. So it can be `Check file description of `. You can use `TKit.assertDirectoryExists()` as a reference -https://github.com/openjdk/jdk/blob/bc6148407e629bd99fa5a8577ebd90320610f349/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TKit.java#L683 - PR: https://git.openjdk.java.net/jdk/pull/7399
Re: RFR: 8279995: jpackage --add-launcher option should allow overriding description [v2]
On Fri, 11 Feb 2022 21:22:44 GMT, Alexander Matveev
wrote:
>> Added ability to override description for additional launchers via
>> "description" property.
>
> Alexander Matveev has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8279995: jpackage --add-launcher option should allow overriding description
> [v2]
test/jdk/tools/jpackage/helpers/jdk/jpackage/test/AdditionalLauncher.java line
90:
> 88: .findFirst().orElse(null);
> 89:
> 90: return entry == null ? null : entry.getValue();
This can be simply
`rawProperties.stream().findAny(item -> item.getKey().equals(key)).map(e ->
e.getValue()).orElse(null);`
Or slightly better:
public String getRawPropertyValue(String key, Supplier getDefault) {
return rawProperties.stream().findAny(item ->
item.getKey().equals(key)).map(e -> e.getValue()).orElseGet(getDefault);
}
Then we can create a function that will return the expected description of an
additional launcher:
private String getDesciption(JPackageCommand cmd) {
return getRawPropertyValue("description", () ->
cmd.getArgumentValue("--description", unused -> "Unknown"));
}
This will let you avoid `if (expectedDescription != null)` checks and
**always** verify launcher description.
test/jdk/tools/jpackage/helpers/jdk/jpackage/test/AdditionalLauncher.java line
275:
> 273:
> expectedDescription.equals(lines.get(i).trim());
> 274: }
> 275: }
This piece of code can be placed in `WindowsHelper.getExecutableDesciption(Path
pathToExeFile)` function to make it reusable in other tests if needed. This way
it can be used to verify the description of the main launcher.
test/jdk/tools/jpackage/helpers/jdk/jpackage/test/AdditionalLauncher.java line
277:
> 275: }
> 276: }
> 277: TKit.assertTrue(descriptionIsValid, "Invalid file
> description");
I'd use `TKit.assertEquals()` to compare the expected description with the
actual one. This will produce a meaningful error message in log output in case
they don't match.
-
PR: https://git.openjdk.java.net/jdk/pull/7399
Re: RFR: 8279995: jpackage --add-launcher option should allow overriding description
On Wed, 9 Feb 2022 07:37:42 GMT, Alexander Matveev wrote: > Added ability to override description for additional launchers via > "description" property. Unfortunately, manual testing adds zero value to automated test runs. This feature can be covered with automated tests so it should be. - PR: https://git.openjdk.java.net/jdk/pull/7399
Re: RFR: 8279995: jpackage --add-launcher option should allow overriding description
On Wed, 9 Feb 2022 18:53:35 GMT, Alexander Matveev wrote:
>> test/jdk/tools/jpackage/share/AddLauncherTest.java line 93:
>>
>>> 91: new AdditionalLauncher("Baz2")
>>> 92: .setDefaultArguments()
>>> 93: .addRawProperties(Map.entry("description", "Baz2
>>> Description"))
>>
>> How expected description is verified in the test?
>
> I do not think that we have ability to check description on executable files.
> I added it for manual verification.
Powershell can be used to extract the description from an executable. E.g.:
$ powershell -NoLogo -NoProfile -Command "(Get-Item
build\\windows-x64\\images\\jdk\\bin\\java.exe).VersionInfo | select
FileDescription"
FileDescription
---
Java(TM) Platform SE binary
You can create jdk.jpackage.test.AdditionalLauncher.verifyDescription()
function that will call this script and call this function from
jdk.jpackage.test.AdditionalLauncher.verify().
-
PR: https://git.openjdk.java.net/jdk/pull/7399
Re: RFR: 8279995: jpackage --add-launcher option should allow overriding description
On Wed, 9 Feb 2022 07:37:42 GMT, Alexander Matveev wrote:
> Added ability to override description for additional launchers via
> "description" property.
I don't quite understand how these changes affect the description of launcher
executables on Windows. I'd expect changes at least in
https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WindowsAppImageBuilder.java#L97.
Can you elaborate, please?
test/jdk/tools/jpackage/share/AddLauncherTest.java line 93:
> 91: new AdditionalLauncher("Baz2")
> 92: .setDefaultArguments()
> 93: .addRawProperties(Map.entry("description", "Baz2
> Description"))
How expected description is verified in the test?
-
PR: https://git.openjdk.java.net/jdk/pull/7399
Integrated: 8257434: jpackage fails to create rpm on Fedora Linux
On Tue, 1 Dec 2020 23:54:11 GMT, Alexey Semenyuk wrote: > Add missing quotes to `%if` expressions in spec template. Required by > rpmbuild 4.16.0 This pull request has now been integrated. Changeset: 541c7f74 Author:Alexey Semenyuk URL: https://git.openjdk.java.net/jdk/commit/541c7f74bbe0ffbacfa802e9e0d6cb6c63d81b10 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod 8257434: jpackage fails to create rpm on Fedora Linux Reviewed-by: almatvee, herrick - PR: https://git.openjdk.java.net/jdk/pull/1551
Re: Integrated: 8257434: jpackage fails to create rpm on Fedora Linux
On Tue, 1 Dec 2020 23:54:11 GMT, Alexey Semenyuk wrote: > Add missing quotes to `%if` expressions in spec template. Required by > rpmbuild 4.16.0 @sashamatveev @andyherrick please review - PR: https://git.openjdk.java.net/jdk/pull/1551
Integrated: 8257434: jpackage fails to create rpm on Fedora Linux
Add missing quotes to `%if` expressions in spec template. Required by rpmbuild 4.16.0 - Commit messages: - 8257434: jpackage fails to create rpm on Fedora Linux Changes: https://git.openjdk.java.net/jdk/pull/1551/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1551=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257434 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/1551.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1551/head:pull/1551 PR: https://git.openjdk.java.net/jdk/pull/1551
Re: [jdk18] RFR: 8279370: jdk.jpackage/share/native/applauncher/JvmLauncher.cpp fails to build with GCC 6.3.0
On Mon, 3 Jan 2022 08:10:27 GMT, Aleksey Shipilev wrote: > Seems like a missing include. C++ docs say `offsetof` is from ``, > adding that include explicitly fixes the build. Seems to only happen with > older GCCs, but it seems to be a happy accident it works on newer ones, > probably through the transitive include somewhere. > > Additional testing: > - [x] Linux x86_64 fastdebug `tools/jpackage` tests > - [x] Linux x86_64 release `tools/jpackage` tests Marked as reviewed by asemenyuk (Reviewer). - PR: https://git.openjdk.java.net/jdk18/pull/74
Re: [jdk18] RFR: 8278907: JPackage test - SigningPackageTest is failed with runtime exception
On Fri, 17 Dec 2021 03:28:12 GMT, Alexander Matveev wrote: > This is regression from JDK-8263155. MacHelper.java is now calling test > verification callback with all content in DMG root. SigningPackageTest > expects only path with app name in it and thus it fails when trying to verify > app inside ".background" folder. Fixed by checking that provided path for > verification is actually an application we expecting. All other paths are > ignored. Marked as reviewed by asemenyuk (Reviewer). - PR: https://git.openjdk.java.net/jdk18/pull/42
Re: [jdk18] RFR: 8278233: [macos] tools/jpackage tests timeout due to /usr/bin/osascript
On Tue, 14 Dec 2021 06:10:51 GMT, Alexander Matveev wrote: > This is regression from JDK-8276837. exec() was passing INFINITE_TIMEOUT > instead of actual value of timeout variable. Execution of osascript was > running without timeout and thus several tests timeout. Osascript hang during > test execution is intermittent issue. > > Also, removed IconTest.java and MultiNameTwoPhaseTest.java from > ProblemList.txt. Marked as reviewed by asemenyuk (Reviewer). - PR: https://git.openjdk.java.net/jdk18/pull/18
RFR: 8278311: Debian packaging doesn't work
8278311: Debian packaging doesn't work - Commit messages: - Changes from another fix removed - 8278311: Debian packaging doesn't work Changes: https://git.openjdk.java.net/jdk/pull/6726/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6726=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278311 Stats: 33 lines in 2 files changed: 26 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/6726.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6726/head:pull/6726 PR: https://git.openjdk.java.net/jdk/pull/6726
Re: RFR: JDK-8276837: [macos]: Error when signing the additional launcher
On Wed, 1 Dec 2021 21:35:01 GMT, Andy Herrick wrote: > - We need to unsign all executables and libraries in the app-image before > signing. (not just those in the runtime). > - Clean up excessive output by executing the individual file sign and > unsigning commands in quiet mode. > - Add conditions in SigningAppImageTest to test signing of additional > launchers. Marked as reviewed by asemenyuk (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6654
Re: RFR: JDK-8276837: [macos]: Error when signing the additional launcher
On Wed, 1 Dec 2021 14:25:52 GMT, Andy Herrick wrote: > Before signing, unsign all executables and libraries (not just those in > runtime). > Also, run individual file sign and unsign commands in quiet mode. > Also, add test case to SigningAppImageTest to test that signing app that has > additional launcher works, and results in validly signed launcher and > additional launcher (original reported problem). Changes requested by asemenyuk (Reviewer). test/jdk/tools/jpackage/macosx/SigningAppImageTest.java line 95: > 93: SigningBase.verifyCodesign(launcherPath, true); > 94: SigningBase.verifyCodesign(testALPath, true); > 95: } Would it make sense to extend the existing test with additional launcher checks instead of creating another one? Packaging of a full JDK with signing probably takes a while - PR: https://git.openjdk.java.net/jdk/pull/6636
Re: RFR: 8277647: [REDO] JDK-8277507 Add jlink.debug system property while launching jpackage tests to help diagonize recent intermittent failures
On 11/24/2021 8:35 AM, Andy Herrick wrote:
Wait - the original change, 'addArgument("-J-Djlink.debug=true");'
adds "-D-J..." as a jpackage arg. This is not a supported command
line option, I'm not sure why it is not throwing an error all the
time, but you need to use addArgument("--java-option
-Djlink.debug=true" ); instead.
This would add -Djlink.debug=true to java options of an app, right? But
we need -Djlink.debug=true for jlink launched from jpackage.
- Alexey
I'll look into why "-J..." is being silently ignored (at least on
windows) and not throwing a invalid argument exception.
/Andy
On 11/24/2021 4:03 AM, Jaikiran Pai wrote:
Can I please get a review of this change which adds
`jlink.debug=true` system property while launching `jpackage` tests?
The previous fix for this in https://github.com/openjdk/jdk/pull/6491
didn't take into account the part where the `jpackage` tool gets
launched as a `ToolProvider` from some of these tests. This resulted
in a large number of tests failing (across different OS) in `tier2`
with errors like:
Error: Invalid Option: [-J-Djlink.debug=true]
In this current PR, the changed code now takes into account the
possibility of `jpackage` being launched as a `ToolProvider` and in
such cases doesn't add this option. To achieve this, the adding of
this argument is delayed till when the actual execution is about to
happen and thus it's now done in the
`adjustArgumentsBeforeExecution()` method of the jpackage test
framework.
With this change, I have now run the `jdk:tier2` locally on a macos
instance and the tests have all passed:
Test results: passed: 3,821; failed: 3
Report written to
jdk/build/macosx-x86_64-server-release/test-results/jtreg_test_jdk_tier2/html/report.html
Results written to
jdk/build/macosx-x86_64-server-release/test-support/jtreg_test_jdk_tier2
Error: Some tests failed or other problems occurred.
Finished running test 'jtreg:test/jdk:tier2'
Test report is stored in
build/macosx-x86_64-server-release/test-results/jtreg_test_jdk_tier2
==
Test summary
==
TEST TOTAL PASS
FAIL ERROR
jtreg:test/jdk:tier2 3824 3821 3 0 <<
==
The 3 failing tests are unrelated to this change and belong to the
`java/nio/channels/DatagramChannel/` test package.
Furthermore, I've looked into the generated logs of the following
tests to verify that the `-J-Djlink.debug=true` does get passed in
relevant tests and doesn't in those that failed previously in `tier2`:
test/jdk/tools/jpackage/share/MultiLauncherTwoPhaseTest.java
test/jdk/tools/jpackage/macosx/NameWithSpaceTest.java
test/jdk/tools/jpackage/share/ArgumentsTest.java
A sample from one of the logs where this system property is expected
to be passed along:
TRACE: exec: Execute
[jdk/build/macosx-x86_64-server-release/images/jdk/bin/jpackage
--input ./test/input --dest ./test/output --name "Name With Space"
--type pkg --main-jar hello.jar --main-class Hello
-J-Djlink.debug=true --verbose](15); inherit I/O...
I would still like to request someone with access to CI or other OSes
(like Windows and Linux) to help test `tier2` against this PR.
-
Commit messages:
- 8277647: [REDO] JDK-8277507 Add jlink.debug system property while
launching jpackage tests to help diagonize recent intermittent failures
Changes: https://git.openjdk.java.net/jdk/pull/6534/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6534=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8277647
Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod
Patch: https://git.openjdk.java.net/jdk/pull/6534.diff
Fetch: git fetch https://git.openjdk.java.net/jdk
pull/6534/head:pull/6534
PR: https://git.openjdk.java.net/jdk/pull/6534
Integrated: 8277429: Conflicting jpackage static library name
On Sat, 20 Nov 2021 03:26:51 GMT, Alexey Semenyuk wrote: > 8277429: Conflicting jpackage static library name This pull request has now been integrated. Changeset: e3911a85 Author: Alexey Semenyuk URL: https://git.openjdk.java.net/jdk/commit/e3911a8532e9b93ba5e65c613bd79864485db5ce Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod 8277429: Conflicting jpackage static library name Reviewed-by: almatvee, herrick, erikj - PR: https://git.openjdk.java.net/jdk/pull/6485
RFR: 8277429: Conflicting jpackage static library name
8277429: Conflicting jpackage static library name - Commit messages: - 8277429: Conflicting jpackage static library name Changes: https://git.openjdk.java.net/jdk/pull/6485/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6485=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277429 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/6485.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6485/head:pull/6485 PR: https://git.openjdk.java.net/jdk/pull/6485
Re: RFR: 8277494: [BACKOUT] JDK-8276150 Quarantined jpackage apps are labeled as "damaged"
On Fri, 19 Nov 2021 20:57:46 GMT, Daniel D. Daugherty wrote: > This reverts commit 936f7ff49ed86adb74bb1ff10d93cb3d7f7d70a0. > > So far we've had 3 failed Tier2 job sets in a row. My Mach5 Tier2 of this > [BACKOUT] has > passed the macosx-aarch64 test task that was failing before. Marked as reviewed by asemenyuk (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6483
Integrated: 8274856: Failing jpackage tests with fastdebug/release build
On Fri, 5 Nov 2021 19:58:01 GMT, Alexey Semenyuk wrote: > The fix is to isolate C++ calls in the separate forked child process on > Linux. > This change requires the passing of JLI command line arguments and values of > environment variables between two processes. This pull request has now been integrated. Changeset: fe45835f Author:Alexey Semenyuk URL: https://git.openjdk.java.net/jdk/commit/fe45835f7cebfccd4544ae19d88bdc7f07560fbe Stats: 278 lines in 8 files changed: 232 ins; 20 del; 26 mod 8274856: Failing jpackage tests with fastdebug/release build Reviewed-by: almatvee, herrick - PR: https://git.openjdk.java.net/jdk/pull/6283
Integrated: 8276084: Linux DEB Bundler: release number in outputted .deb file should be optional
On Thu, 11 Nov 2021 04:07:18 GMT, Alexey Semenyuk wrote: > 8276084: Linux DEB Bundler: release number in outputted .deb file should be > optional This pull request has now been integrated. Changeset: 9046077f Author:Alexey Semenyuk URL: https://git.openjdk.java.net/jdk/commit/9046077fe6ce7bb042fbd0fa1a80537cb4a60581 Stats: 65 lines in 7 files changed: 52 ins; 1 del; 12 mod 8276084: Linux DEB Bundler: release number in outputted .deb file should be optional Reviewed-by: almatvee, herrick - PR: https://git.openjdk.java.net/jdk/pull/6345
RFR: 8276084: Linux DEB Bundler: release number in outputted .deb file should be optional
8276084: Linux DEB Bundler: release number in outputted .deb file should be optional - Commit messages: - Bugfix - Bugfix - Bugfix - 8276084: Linux DEB Bundler: release number in outputted .deb file should be optional Changes: https://git.openjdk.java.net/jdk/pull/6345/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6345=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276084 Stats: 65 lines in 7 files changed: 52 ins; 1 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/6345.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6345/head:pull/6345 PR: https://git.openjdk.java.net/jdk/pull/6345
RFR: 8274856: Failing jpackage tests with fastdebug/release build
The fix is to isolate C++ calls in the separate forked child process on Linux. This change requires the passing of JLI command line arguments and values of environment variables between two processes. - Commit messages: - Whitespace clean up - 8274856: Failing jpackage tests with fastdebug/release build Changes: https://git.openjdk.java.net/jdk/pull/6283/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6283=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274856 Stats: 278 lines in 8 files changed: 232 ins; 20 del; 26 mod Patch: https://git.openjdk.java.net/jdk/pull/6283.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6283/head:pull/6283 PR: https://git.openjdk.java.net/jdk/pull/6283
Re: RFR: JDK-8276562: Fix to JDK-8263155 left out the help text changes
On Fri, 5 Nov 2021 17:21:01 GMT, Andy Herrick wrote: > JDK-8276562: Fix to JDK-8263155 left out the help text changes Marked as reviewed by asemenyuk (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6281
Re: RFR: JDK-8263155: Allow additional contents for DMG [v2]
On Thu, 21 Oct 2021 15:36:36 GMT, Andy Herrick wrote: >> JDK-8263155: Allow additional contents for DMG > > Andy Herrick has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains five commits: > > - Merge branch 'master' into JDK-8263155 > - Merge branch 'master' into JDK-8263155 > - JDK-8263155: Allow additional contents for DMG > - JDK-8263155: Allow additional contents for DMG > - JDK-8263155: Allow additional contents for DMG Marked as reviewed by asemenyuk (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5912
Re: RFR: 8274346: Support for additional content in an app-image. [v2]
On Wed, 6 Oct 2021 18:53:39 GMT, Andy Herrick wrote: >> 8274346: Support for additional content in an app-image. > > Andy Herrick has updated the pull request incrementally with one additional > commit since the last revision: > > JDK-8274346: Support for additional content in an app-image. Marked as reviewed by asemenyuk (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5780
Re: RFR: 8274346: Support for additional content in an app-image.
On Thu, 30 Sep 2021 18:51:49 GMT, Andy Herrick wrote:
> 8274346: Support for additional content in an app-image.
Changes requested by asemenyuk (Reviewer).
test/jdk/tools/jpackage/share/AppContentTest.java line 97:
> 95: for (String p : paths) {
> 96: Path name = Path.of(p).getFileName();
> 97:
> TKit.assertTrue(Files.exists(contentDir.resolve(name)),
I'd suggest to use `TKit.assertPathExists()` instead of
`TKit.assertTrue(Files.exists(...))`
-
PR: https://git.openjdk.java.net/jdk/pull/5780
Re: RFR: JDK-8274087: Windows DLL path not set correctly.
On Thu, 23 Sep 2021 20:03:29 GMT, Andy Herrick wrote: > JDK-8274087: Windows DLL path not set correctly. Marked as reviewed by asemenyuk (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5663
Re: RFR: 8272815: jpackage --type rpm produces an error: Invalid or unsupported type: [null] [v3]
> Fix jpackage error output when "--type" CLI option is missing and jpackage > detects that it can't build native packages in the environment. Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: dummy commit - Changes: - all: https://git.openjdk.java.net/jdk/pull/5512/files - new: https://git.openjdk.java.net/jdk/pull/5512/files/44cf9fde..a7534c7e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=5512=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=5512=01-02 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5512.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5512/head:pull/5512 PR: https://git.openjdk.java.net/jdk/pull/5512
Integrated: 8272815: jpackage --type rpm produces an error: Invalid or unsupported type: [null]
On Tue, 14 Sep 2021 17:21:29 GMT, Alexey Semenyuk wrote: > Fix jpackage error output when "--type" CLI option is missing and jpackage > detects that it can't build native packages in the environment. This pull request has now been integrated. Changeset: a3ca7702 Author: Alexey Semenyuk URL: https://git.openjdk.java.net/jdk/commit/a3ca770227065aecc2df9f9c711687fd8ec5d34e Stats: 18 lines in 2 files changed: 2 ins; 4 del; 12 mod 8272815: jpackage --type rpm produces an error: Invalid or unsupported type: [null] Reviewed-by: herrick, almatvee - PR: https://git.openjdk.java.net/jdk/pull/5512
Re: RFR: 8272815: jpackage --type rpm produces an error: Invalid or unsupported type: [null] [v2]
> Fix jpackage error output when "--type" CLI option is missing and jpackage > detects that it can't build native packages in the environment. Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: dummy commit - Changes: - all: https://git.openjdk.java.net/jdk/pull/5512/files - new: https://git.openjdk.java.net/jdk/pull/5512/files/caac338f..44cf9fde Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=5512=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=5512=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5512.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5512/head:pull/5512 PR: https://git.openjdk.java.net/jdk/pull/5512
RFR: 8272815: jpackage --type rpm produces an error: Invalid or unsupported type: [null]
Fix jpackage error output when "--type" CLI option is missing and jpackage detects that it can't build native packages in the environment. - Commit messages: - 8272815: jpackage --type rpm produces an error: Invalid or unsupported type: [null] Changes: https://git.openjdk.java.net/jdk/pull/5512/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5512=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272815 Stats: 18 lines in 2 files changed: 2 ins; 4 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/5512.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5512/head:pull/5512 PR: https://git.openjdk.java.net/jdk/pull/5512
Re: RFR: JDK-8273040: Turning off JpAllowDowngrades (or Upgrades)
On Tue, 14 Sep 2021 13:38:42 GMT, Andy Herrick wrote: > JDK-8273040: Turning off JpAllowDowngrades (or Upgrades) Marked as reviewed by asemenyuk (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5509
Re: RFR: 8273595: tools/jpackage tests do not work on apt-based Linux distros like Debian
On Fri, 10 Sep 2021 12:03:48 GMT, Ao Qi wrote: > A similar issue on Ubuntu has been fixed by > [JDK-8238953](https://bugs.openjdk.java.net/browse/JDK-8238953). However, > tools/jpackage tests do not work on Debian Linux or other apt-based Linux, > when rpm package is installed. This issue proposes a general fix for > apt-based Linux. Sorry, I issued the "integrate" command as I got confused with the "contributor" comment. - PR: https://git.openjdk.java.net/jdk/pull/5462
Re: RFR: 8273595: tools/jpackage tests do not work on apt-based Linux distros like Debian
On Fri, 10 Sep 2021 12:03:48 GMT, Ao Qi wrote: > A similar issue on Ubuntu has been fixed by > [JDK-8238953](https://bugs.openjdk.java.net/browse/JDK-8238953). However, > tools/jpackage tests do not work on Debian Linux or other apt-based Linux, > when rpm package is installed. This issue proposes a general fix for > apt-based Linux. Marked as reviewed by asemenyuk (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5462
Re: [jdk17] RFR: JDK-8273592: Backout JDK-8271868
On Fri, 10 Sep 2021 13:18:49 GMT, Andy Herrick wrote: > JDK-8271868 was pushed to JDK17 instead of jdk17u. > This change is to back it out Marked as reviewed by asemenyuk (Reviewer). - PR: https://git.openjdk.java.net/jdk17/pull/307
Re: [jdk17] RFR: JDK-8272639: jpackaged applications using microphone on mac
On Thu, 9 Sep 2021 20:14:01 GMT, Andy Herrick wrote: > backport from jdk-18 Marked as reviewed by asemenyuk (Reviewer). - PR: https://git.openjdk.java.net/jdk17/pull/306
Re: [jdk17] RFR: 8271868: Warn user when using mac-sign option with unsigned app-image.
On Thu, 9 Sep 2021 16:36:44 GMT, Andy Herrick wrote: > This is a backport from JDK-18 Marked as reviewed by asemenyuk (Reviewer). - PR: https://git.openjdk.java.net/jdk17/pull/305
Integrated: 8271170: Add unit test for what jpackage app launcher puts in the environment
On Mon, 9 Aug 2021 17:02:55 GMT, Alexey Semenyuk wrote: > Added jtreg test to verify jpackage launcher adds app dir to > `java.library.path` system property. > Removed unused test/jdk/tools/jpackage/apps/installer/Hello.java. > Moved test/jdk/tools/jpackage/apps/image/Hello.java to > test/jdk/tools/jpackage/apps/Hello.java. This pull request has now been integrated. Changeset: 44f137ff Author:Alexey Semenyuk URL: https://git.openjdk.java.net/jdk/commit/44f137ff9c0229ab2d5eccd9ebaadf8db11f386d Stats: 330 lines in 7 files changed: 200 ins; 116 del; 14 mod 8271170: Add unit test for what jpackage app launcher puts in the environment Reviewed-by: almatvee, herrick - PR: https://git.openjdk.java.net/jdk/pull/5056
Re: RFR: 8271170: Add unit test for what jpackage app launcher puts in the environment [v4]
> Added jtreg test to verify jpackage launcher adds app dir to > `java.library.path` system property. > Removed unused test/jdk/tools/jpackage/apps/installer/Hello.java. > Moved test/jdk/tools/jpackage/apps/image/Hello.java to > test/jdk/tools/jpackage/apps/Hello.java. Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: dummy commit - Changes: - all: https://git.openjdk.java.net/jdk/pull/5056/files - new: https://git.openjdk.java.net/jdk/pull/5056/files/27e82df3..3e7011e7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=5056=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk=5056=02-03 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5056.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5056/head:pull/5056 PR: https://git.openjdk.java.net/jdk/pull/5056
Integrated: 8272328: java.library.path is not set properly by Windows jpackage app launcher
On Wed, 11 Aug 2021 17:52:57 GMT, Alexey Semenyuk wrote: > Restart window app launcher to make changes made to `PATH` env variable > visible to JLI code in > https://github.com/openjdk/jdk/blob/master/src/hotspot/os/windows/os_windows.cpp#L347 This pull request has now been integrated. Changeset: cd2dbe5f Author: Alexey Semenyuk URL: https://git.openjdk.java.net/jdk/commit/cd2dbe5f007baf81ae9262c1152917e620970621 Stats: 75 lines in 4 files changed: 63 ins; 5 del; 7 mod 8272328: java.library.path is not set properly by Windows jpackage app launcher Reviewed-by: herrick, almatvee - PR: https://git.openjdk.java.net/jdk/pull/5090
RFR: 8272328: java.library.path is not set properly by Windows jpackage app launcher
Restart window app launcher to make changes made to `PATH` env variable visible to JLI code in https://github.com/openjdk/jdk/blob/master/src/hotspot/os/windows/os_windows.cpp#L347 - Commit messages: - 8272328: java.library.path is not set properly by Windows jpackage app launcher Changes: https://git.openjdk.java.net/jdk/pull/5090/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5090=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272328 Stats: 75 lines in 4 files changed: 63 ins; 5 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/5090.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5090/head:pull/5090 PR: https://git.openjdk.java.net/jdk/pull/5090
Re: RFR: 8271170: Add unit test for what jpackage app launcher puts in the environment [v3]
On Wed, 11 Aug 2021 15:20:00 GMT, Alexey Semenyuk wrote: >> Added jtreg test to verify jpackage launcher adds app dir to >> `java.library.path` system property. >> Removed unused test/jdk/tools/jpackage/apps/installer/Hello.java. >> Moved test/jdk/tools/jpackage/apps/image/Hello.java to >> test/jdk/tools/jpackage/apps/Hello.java. > > Alexey Semenyuk has updated the pull request incrementally with one > additional commit since the last revision: > > Removed unused output to file in the new PrintEnv test app. These changes will be pushed after https://bugs.openjdk.java.net/browse/JDK-8272328 is fixed. - PR: https://git.openjdk.java.net/jdk/pull/5056
Re: RFR: 8271170: Add unit test for what jpackage app launcher puts in the environment [v3]
> Added jtreg test to verify jpackage launcher adds app dir to > `java.library.path` system property. > Removed unused test/jdk/tools/jpackage/apps/installer/Hello.java. > Moved test/jdk/tools/jpackage/apps/image/Hello.java to > test/jdk/tools/jpackage/apps/Hello.java. Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: Removed unused output to file in the new PrintEnv test app. - Changes: - all: https://git.openjdk.java.net/jdk/pull/5056/files - new: https://git.openjdk.java.net/jdk/pull/5056/files/4c0891dd..27e82df3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=5056=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=5056=01-02 Stats: 13 lines in 2 files changed: 0 ins; 11 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5056.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5056/head:pull/5056 PR: https://git.openjdk.java.net/jdk/pull/5056
Re: RFR: 8271170: Add unit test for what jpackage app launcher puts in the environment [v2]
> Added jtreg test to verify jpackage launcher adds app dir to > `java.library.path` system property. > Removed unused test/jdk/tools/jpackage/apps/installer/Hello.java. > Moved test/jdk/tools/jpackage/apps/image/Hello.java to > test/jdk/tools/jpackage/apps/Hello.java. Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: Handle duplicate elements in `java.library.path` system property value. - Changes: - all: https://git.openjdk.java.net/jdk/pull/5056/files - new: https://git.openjdk.java.net/jdk/pull/5056/files/bda38d39..4c0891dd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=5056=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=5056=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5056.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5056/head:pull/5056 PR: https://git.openjdk.java.net/jdk/pull/5056
RFR: 8271170: Add unit test for what jpackage app launcher puts in the environment
Added jtreg test to verify jpackage launcher adds app dir to `java.library.path` system property. Removed unused test/jdk/tools/jpackage/apps/installer/Hello.java. Moved test/jdk/tools/jpackage/apps/image/Hello.java to test/jdk/tools/jpackage/apps/Hello.java. - Commit messages: - dummy commit - Whitespace clean up - 8271170: Add unit test for what jpackage app launcher puts in the environment Changes: https://git.openjdk.java.net/jdk/pull/5056/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5056=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271170 Stats: 342 lines in 7 files changed: 212 ins; 116 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/5056.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5056/head:pull/5056 PR: https://git.openjdk.java.net/jdk/pull/5056
Re: RFR: 8271868: Warn user when using mac-sign option with unsigned app-image. [v2]
On Thu, 5 Aug 2021 17:07:13 GMT, Andy Herrick wrote: >> 8271868: Warn user when using mac-sign option with unsigned app-image. > > Andy Herrick has updated the pull request incrementally with one additional > commit since the last revision: > > JDK-8271868: Warn user when using mac-sign option with unsigned app-image. Marked as reviewed by asemenyuk (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5004
