RFR: 8332110: [macos] jpackage tries to sign added files without the --mac-sign option
This issue is reproducible with and without `--mac-sign`. jpackage will "_ad-hoc_" sign application bundle when `--mac-sign` is not specified by using pseudo-identity "_-_". This is why jpackage tries to sign added files and this is expected behavior by jpackage. "codesign" fails since added content made application bundle structure invalid. There is nothing we can do on jpackage side to sign such invalid bundles. As proposed solution we will output possible reason for "codesign" failure if it fails and `--app-content` was specified and possible solution. Proposed message: "One of the possible reason for "codesign" failure is additional content provided via "--app-content", which made application bundle structure invalid. Make sure to provide additional content in a way it will not break application bundle structure, otherwise add additional content as post-processing step." Example: Lets assume we have "ReadMe" folder with "ReadMe.txt" file in it. 1) jpackage --type app-image -n Test --app-content ReadMe/ReadMe.txt ... "codesign" will fail with "In subcomponent: Test.app/Contents/ReadMe.txt". This is expected and "ReadMe.txt" placed in "Test.app/Contents" which is also expected. 2) jpackage --type app-image -n Test --app-content ReadMe ... Works and "ReadMe.txt" will be placed under "Test.app/Contents/ReadMe". Sample output before fix: Error: "codesign" failed with following output: Test.app: replacing existing signature Test.app: code object is not signed at all In subcomponent: Test.app/Contents/ReadMe.txt Sample output after fix: One of the possible reason for "codesign" failure is additional content provided via "--app-content", which made application bundle structure invalid. Make sure to provide additional content in a way it will not break application bundle structure, otherwise add additional content as post-processing step. Error: "codesign" failed with following output: Test.app: replacing existing signature Test.app: code object is not signed at all In subcomponent: Test.app/Contents/ReadMe.txt - Commit messages: - 8332110: jpackage tries to sign added files without the --mac-sign option Changes: https://git.openjdk.org/jdk/pull/19377/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19377&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8332110 Stats: 38 lines in 6 files changed: 24 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/19377.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19377/head:pull/19377 PR: https://git.openjdk.org/jdk/pull/19377
Re: RFR: 8332110: [macos] jpackage tries to sign added files without the --mac-sign option
Hi Michael, > Doesn’t this still leave you with an application that isn’t validly signed? > And probably won’t run because of that. Yes, it will leave you with an application that isn’t signed. I was able to run such application on same machine as it was generated by jpackage. > For your example. This almost seems like an Apple bug if you can add a > directory to the Contents directory but not a file? Not sure if it is an Apple bug. > Would it also generally be a good idea to include a final codesign verify to > fail the build if something is wrong with the signature? Yes, you already suggested it. See https://bugs.openjdk.org/browse/JDK-8318063 and it was closed as won’t fix because such verification is redundant. Thanks, Alexander From: Michael Hall Date: Friday, May 24, 2024 at 1:47 AM To: Alexander Matveev Cc: core-libs-dev Subject: Re: RFR: 8332110: [macos] jpackage tries to sign added files without the --mac-sign option On May 24, 2024, at 3:08 AM, Michael Hall wrote: On May 23, 2024, at 8:13 PM, Alexander Matveev mailto:almat...@openjdk.org>> wrote: otherwise add additional content as post-processing step. Doesn’t this still leave you with an application that isn’t validly signed? And probably won’t run because of that. 2) jpackage --type app-image -n Test --app-content ReadMe ... For your example. This almost seems like an Apple bug if you can add a directory to the Contents directory but not a file? Sorry I made my prior off-list. Would it also generally be a good idea to include a final codesign verify to fail the build if something is wrong with the signature? Something like… echo '***' echo 'verifying signature' echo '***' codesign -v --verbose=4 outputdir/HalfPipe.app Expected output… *** verifying signature *** outputdir/HalfPipe.app: valid on disk outputdir/HalfPipe.app: satisfies its Designated Requirement I think I have suggested this before but don’t remember if I did an enhancement request. Maybe you do that and I’m just not aware of it if it doesn’t appear in the jpackage output.
Re: RFR: 8332110: [macos] jpackage tries to sign added files without the --mac-sign option
On Fri, 24 May 2024 01:08:03 GMT, Alexander Matveev wrote: > This issue is reproducible with and without `--mac-sign`. jpackage will > "_ad-hoc_" sign application bundle when `--mac-sign` is not specified by > using pseudo-identity "_-_". This is why jpackage tries to sign added files > and this is expected behavior by jpackage. "codesign" fails since added > content made application bundle structure invalid. There is nothing we can do > on jpackage side to sign such invalid bundles. As proposed solution we will > output possible reason for "codesign" failure if it fails and `--app-content` > was specified and possible solution. Proposed message: "One of the possible > reason for "codesign" failure is additional content provided via > "--app-content", which made application bundle structure invalid. Make sure > to provide additional content in a way it will not break application bundle > structure, otherwise add additional content as post-processing step." > > Example: > Lets assume we have "ReadMe" folder with "ReadMe.txt" file in it. > 1) jpackage --type app-image -n Test --app-content ReadMe/ReadMe.txt ... > "codesign" will fail with "In subcomponent: Test.app/Contents/ReadMe.txt". > This is expected and "ReadMe.txt" placed in "Test.app/Contents" which is also > expected. > 2) jpackage --type app-image -n Test --app-content ReadMe ... > Works and "ReadMe.txt" will be placed under "Test.app/Contents/ReadMe". > > Sample output before fix: > > Error: "codesign" failed with following output: > Test.app: replacing existing signature > Test.app: code object is not signed at all > In subcomponent: Test.app/Contents/ReadMe.txt > > > Sample output after fix: > > One of the possible reason for "codesign" failure is additional content > provided via "--app-content", which made application bundle structure > invalid. Make sure to provide additional content in a way it will not break > application bundle structure, otherwise add additional content as > post-processing step. > Error: "codesign" failed with following output: > Test.app: replacing existing signature > Test.app: code object is not signed at all > In subcomponent: Test.app/Contents/ReadMe.txt @alexeysemenyukoracle please review - PR Comment: https://git.openjdk.org/jdk/pull/19377#issuecomment-2136148629
Re: RFR: 8333116: test/jdk/tools/jpackage/share/ServiceTest.java test fails
On Tue, 28 May 2024 20:13:24 GMT, Alexey Semenyuk wrote: > Add missing "--add-opens jdk.jpackage/jdk.jpackage.internal=ALL-UNNAMED" to > the test descriptor Looks good. - Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19436#pullrequestreview-2083892285
Re: RFR: 8333307: Don't suppress jpackage logging in tests when it is detecting packaging tools in the system
On Thu, 30 May 2024 20:26:02 GMT, Alexey Semenyuk wrote: > Change jpackage tests output from: > > > [19:16:29.586] Create: SimplePackageTest.test > [19:16:29.587] [ RUN ] SimplePackageTest.test > [19:16:29.663] TRACE: Bundler rpm supported > [19:16:29.674] TRACE: Actions: [[initialize], [create], [unpack], > [verify-install], [finalize]] > > > to: > > > [19:16:29.586] Create: SimplePackageTest.test > [19:16:29.587] [ RUN ] SimplePackageTest.test > [19:16:29.621] Running dpkg > [19:16:29.633] Running dpkg-deb > [19:16:29.651] Running rpmbuild > [19:16:29.663] TRACE: Bundler rpm supported > [19:16:29.674] TRACE: Actions: [[initialize], [create], [unpack], > [verify-install], [finalize]] Looks good, but I am confused why it is targeted to 24? I think you need to postpone integration until 24 or target it to 23. - PR Comment: https://git.openjdk.org/jdk/pull/19489#issuecomment-2140961328
Re: RFR: 8332110: [macos] jpackage tries to sign added files without the --mac-sign option [v2]
> This issue is reproducible with and without `--mac-sign`. jpackage will > "_ad-hoc_" sign application bundle when `--mac-sign` is not specified by > using pseudo-identity "_-_". This is why jpackage tries to sign added files > and this is expected behavior by jpackage. "codesign" fails since added > content made application bundle structure invalid. There is nothing we can do > on jpackage side to sign such invalid bundles. As proposed solution we will > output possible reason for "codesign" failure if it fails and `--app-content` > was specified and possible solution. Proposed message: "One of the possible > reason for "codesign" failure is additional content provided via > "--app-content", which made application bundle structure invalid. Make sure > to provide additional content in a way it will not break application bundle > structure, otherwise add additional content as post-processing step." > > Example: > Lets assume we have "ReadMe" folder with "ReadMe.txt" file in it. > 1) jpackage --type app-image -n Test --app-content ReadMe/ReadMe.txt ... > "codesign" will fail with "In subcomponent: Test.app/Contents/ReadMe.txt". > This is expected and "ReadMe.txt" placed in "Test.app/Contents" which is also > expected. > 2) jpackage --type app-image -n Test --app-content ReadMe ... > Works and "ReadMe.txt" will be placed under "Test.app/Contents/ReadMe". > > Sample output before fix: > > Error: "codesign" failed with following output: > Test.app: replacing existing signature > Test.app: code object is not signed at all > In subcomponent: Test.app/Contents/ReadMe.txt > > > Sample output after fix: > > "codesign" failed and additional application content was supplied via the > "--app-content" parameter. Probably the additional content broke the > integrity of the application bundle and caused the failure. Ensure content > supplied via the "--app-content" parameter does not break the integrity of > the application bundle, or add it in the post-processing step. > Error: "codesign" failed with following output: > Test.app: replacing existing signature > Test.app: code object is not signed at all > In subcomponent: Test.app/Contents/ReadMe.txt Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8332110: jpackage tries to sign added files without the --mac-sign option [v2] - Changes: - all: https://git.openjdk.org/jdk/pull/19377/files - new: https://git.openjdk.org/jdk/pull/19377/files/0ad02cbb..7c1973ad Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19377&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19377&range=00-01 Stats: 9 lines in 6 files changed: 1 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/19377.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19377/head:pull/19377 PR: https://git.openjdk.org/jdk/pull/19377
Re: RFR: 8332110: [macos] jpackage tries to sign added files without the --mac-sign option [v2]
On Thu, 30 May 2024 22:54:12 GMT, Alexander Matveev wrote: >> This issue is reproducible with and without `--mac-sign`. jpackage will >> "_ad-hoc_" sign application bundle when `--mac-sign` is not specified by >> using pseudo-identity "_-_". This is why jpackage tries to sign added files >> and this is expected behavior by jpackage. "codesign" fails since added >> content made application bundle structure invalid. There is nothing we can >> do on jpackage side to sign such invalid bundles. As proposed solution we >> will output possible reason for "codesign" failure if it fails and >> `--app-content` was specified and possible solution. Proposed message: "One >> of the possible reason for "codesign" failure is additional content provided >> via "--app-content", which made application bundle structure invalid. Make >> sure to provide additional content in a way it will not break application >> bundle structure, otherwise add additional content as post-processing step." >> >> Example: >> Lets assume we have "ReadMe" folder with "ReadMe.txt" file in it. >> 1) jpackage --type app-image -n Test --app-content ReadMe/ReadMe.txt ... >> "codesign" will fail with "In subcomponent: Test.app/Contents/ReadMe.txt". >> This is expected and "ReadMe.txt" placed in "Test.app/Contents" which is >> also expected. >> 2) jpackage --type app-image -n Test --app-content ReadMe ... >> Works and "ReadMe.txt" will be placed under "Test.app/Contents/ReadMe". >> >> Sample output before fix: >> >> Error: "codesign" failed with following output: >> Test.app: replacing existing signature >> Test.app: code object is not signed at all >> In subcomponent: Test.app/Contents/ReadMe.txt >> >> >> Sample output after fix: >> >> "codesign" failed and additional application content was supplied via the >> "--app-content" parameter. Probably the additional content broke the >> integrity of the application bundle and caused the failure. Ensure content >> supplied via the "--app-content" parameter does not break the integrity of >> the application bundle, or add it in the post-processing step. >> Error: "codesign" failed with following output: >> Test.app: replacing existing signature >> Test.app: code object is not signed at all >> In subcomponent: Test.app/Contents/ReadMe.txt > > Alexander Matveev has updated the pull request incrementally with one > additional commit since the last revision: > > 8332110: jpackage tries to sign added files without the --mac-sign option > [v2] 8332110: jpackage tries to sign added files without the --mac-sign option [v2] - Updated error message as suggested. - PR Comment: https://git.openjdk.org/jdk/pull/19377#issuecomment-2140973262
Re: RFR: 8333307: Don't suppress jpackage logging in tests when it is detecting packaging tools in the system
On Thu, 30 May 2024 20:26:02 GMT, Alexey Semenyuk wrote: > Change jpackage tests output from: > > > [19:16:29.586] Create: SimplePackageTest.test > [19:16:29.587] [ RUN ] SimplePackageTest.test > [19:16:29.663] TRACE: Bundler rpm supported > [19:16:29.674] TRACE: Actions: [[initialize], [create], [unpack], > [verify-install], [finalize]] > > > to: > > > [19:16:29.586] Create: SimplePackageTest.test > [19:16:29.587] [ RUN ] SimplePackageTest.test > [19:16:29.621] Running dpkg > [19:16:29.633] Running dpkg-deb > [19:16:29.651] Running rpmbuild > [19:16:29.663] TRACE: Bundler rpm supported > [19:16:29.674] TRACE: Actions: [[initialize], [create], [unpack], > [verify-install], [finalize]] Marked as reviewed by almatvee (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/19489#pullrequestreview-2089482543
Re: RFR: 8333303: Issues with DottedVersion class
On Thu, 30 May 2024 20:10:05 GMT, Alexey Semenyuk wrote: > - Get rid of DottedVersion#greedy field. > - Add support to save the unrecognizable remainder of the version string > (required to handle Wix4 version string). > - Implement DottedVersion#equals(). > - add DottedVersion#compareComponents(DottedVersion, DottedVersion) that > compares recognized components of the given DottedVersion instances. > - remove DottedVersion#compareTo(String) > > [Edit](https://bugs.openjdk.org/secure/EditComment!default.jspa?id=5130726&commentId=14677610) > [Delete](https://bugs.openjdk.org/secure/DeleteComment!default.jspa?id=5130726&commentId=14677610) Looks good. - Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19488#pullrequestreview-2089507390
Re: RFR: 8332110: [macos] jpackage tries to sign added files without the --mac-sign option [v2]
On Thu, 30 May 2024 14:21:51 GMT, Alexey Semenyuk wrote:
>> Alexander Matveev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8332110: jpackage tries to sign added files without the --mac-sign option
>> [v2]
>
> test/jdk/tools/jpackage/macosx/SigningOptionsTest.java line 97:
>
>> 95: new String[]{"--app-content", TEST_DUKE},
>> 96: null,
>> 97: "\"codesign\" failure is additional content provided
>> via \"--app-content\""},
>
> Why is this not a `One of the possible reason for "{0}" failure is additional
> content provided via "--app-content"`?
It was part of old message. Latest test version has latest message: ""codesign"
failed and additional application content was supplied via the "--app-content"
parameter."
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19377#discussion_r1622884704
Integrated: 8332110: [macos] jpackage tries to sign added files without the --mac-sign option
On Fri, 24 May 2024 01:08:03 GMT, Alexander Matveev wrote: > This issue is reproducible with and without `--mac-sign`. jpackage will > "_ad-hoc_" sign application bundle when `--mac-sign` is not specified by > using pseudo-identity "_-_". This is why jpackage tries to sign added files > and this is expected behavior by jpackage. "codesign" fails since added > content made application bundle structure invalid. There is nothing we can do > on jpackage side to sign such invalid bundles. As proposed solution we will > output possible reason for "codesign" failure if it fails and `--app-content` > was specified and possible solution. Proposed message: "One of the possible > reason for "codesign" failure is additional content provided via > "--app-content", which made application bundle structure invalid. Make sure > to provide additional content in a way it will not break application bundle > structure, otherwise add additional content as post-processing step." > > Example: > Lets assume we have "ReadMe" folder with "ReadMe.txt" file in it. > 1) jpackage --type app-image -n Test --app-content ReadMe/ReadMe.txt ... > "codesign" will fail with "In subcomponent: Test.app/Contents/ReadMe.txt". > This is expected and "ReadMe.txt" placed in "Test.app/Contents" which is also > expected. > 2) jpackage --type app-image -n Test --app-content ReadMe ... > Works and "ReadMe.txt" will be placed under "Test.app/Contents/ReadMe". > > Sample output before fix: > > Error: "codesign" failed with following output: > Test.app: replacing existing signature > Test.app: code object is not signed at all > In subcomponent: Test.app/Contents/ReadMe.txt > > > Sample output after fix: > > "codesign" failed and additional application content was supplied via the > "--app-content" parameter. Probably the additional content broke the > integrity of the application bundle and caused the failure. Ensure content > supplied via the "--app-content" parameter does not break the integrity of > the application bundle, or add it in the post-processing step. > Error: "codesign" failed with following output: > Test.app: replacing existing signature > Test.app: code object is not signed at all > In subcomponent: Test.app/Contents/ReadMe.txt This pull request has now been integrated. Changeset: 9fd0e734 Author:Alexander Matveev URL: https://git.openjdk.org/jdk/commit/9fd0e7349ebf4a49b5c0c7a16c866b5b8e626b53 Stats: 39 lines in 6 files changed: 25 ins; 0 del; 14 mod 8332110: [macos] jpackage tries to sign added files without the --mac-sign option Reviewed-by: asemenyuk - PR: https://git.openjdk.org/jdk/pull/19377
Re: RFR: 8332110: [macos] jpackage tries to sign added files without the --mac-sign option
On Fri, 31 May 2024 20:43:45 GMT, Nir Lisker wrote: > > > For your example. This almost seems like an Apple bug if you can add a > > > directory to the Contents directory but not a file? > > > > > > Not sure if it is an Apple bug. > > Can this be reported to Apple somehow? I do not think that it is an Apple bug. If you look at an Apple documentation [1] about "Placing content in a bundle" you will see highlighted important message that you should not put content in the wrong location. [1] https://developer.apple.com/documentation/bundleresources/placing_content_in_a_bundle?language=objc - PR Comment: https://git.openjdk.org/jdk/pull/19377#issuecomment-2142981609
Re: RFR: 8332110: [macos] jpackage tries to sign added files without the --mac-sign option [v2]
On Fri, 31 May 2024 21:36:56 GMT, Nir Lisker wrote: > I see, but it doesn't say where to put license files, which are usually in > the root. Do you know where these belong? No idea. - PR Comment: https://git.openjdk.org/jdk/pull/19377#issuecomment-2143025767
Re: RFR: 8331977: Crash: SIGSEGV in dlerror()
On Fri, 31 May 2024 14:05:07 GMT, Alexey Semenyuk wrote: > Fix MainClassTest class to use HelloApp.AppOutputVerifier class to run app > launcher instead of raw Executor. This makes MainClassTest test run app > launchers with retries. This change addresses the primary issue. > > Fix inconsistencies in HelloApp.AppOutputVerifier class. It used to provide > API allowing to run launchers without retries. It inconsistently allowed the > execution of launchers with suppressed output (stdout and stderr). It > inconsistently executed launchers with/without PATH removed from the > environment. > > These loopholes were eliminated: > > - stdout and stderr of app launchers is never suppressed; > - PATH env variable is always deleted for app launchers on Windows. It is > not deleted on other platforms. This change sets the correct scope of > [JDK-8254920](https://bugs.openjdk.org/browse/JDK-8254920) fix that > introduced the removal of PATH env variable for app launchers; > - app launchers are always executed with retries unless the launcher is > executed with `jpackage.test.noexit` system property set to `true` indicating > the test app will not terminate on its own. > > Other changes are due to changes in HelloApp.AppOutputVerifier class. Looks good. - Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19502#pullrequestreview-2091922907
Re: RFR: 8333452: Make logging in jdk.jpackage.internal.OverridableResource class configurable
On Mon, 3 Jun 2024 20:29:47 GMT, Alexey Semenyuk wrote: > 8333452: Make logging in jdk.jpackage.internal.OverridableResource class > configurable OverridableResource uses Log.verbose, which will log if -verbose is specified. What do you mean by "OverridableResource class unconditionally writes in the log."? Why "In some situations emitting log messages is not desired."? If we do not need to log them when "-verbose" is specified then lets just remove them. `NoLogging` class is only used by test. Can we modify `OverridableResource` in such way it does not require additional code which is used by test only? This added functionality is not used. It is completely unclear from PR and/or issue description why we need this and how it will be used in the future? - PR Comment: https://git.openjdk.org/jdk/pull/19532#issuecomment-2146189724
Re: RFR: 8319457: Update jpackage to support WiX Toolset 4 on Windows
On Tue, 4 Jun 2024 01:29:15 GMT, Alexey Semenyuk wrote: > > Is there plan to add support for WiX 5? > > This patch supports WiX5 as well. There is not much difference between WiX4 > and WiX5 from jpackage perspective. I'll update the description I assume WiX5 will just work if installed instead of WiX4? Do you think it will make sense to introduce Wix5 ToolsetType in case if we need to do something different between 4 and 5? - PR Comment: https://git.openjdk.org/jdk/pull/19318#issuecomment-2146460825
Re: RFR: 8319457: Update jpackage to support WiX v4 and v5 on Windows [v4]
On Wed, 5 Jun 2024 14:53:09 GMT, Alexey Semenyuk wrote: >> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources.properties >> line 44: >> >>> 42: resource.installdirnotemptydlg-wix-file=Not empty install directory >>> dialog WiX project file >>> 43: resource.launcher-as-service-wix-file=Service installer WiX project file >>> 44: resource.wix-src-conv=XSLT stylesheet converting WiX sources from WiX >>> v3 to WiX v4 format >> >> WiX v4 -> WiX v4/v5 > > The converter does exactly as described, it converts WiX v3 sources into WiX > v4 **format** that can be used with WiX v4 and WiX v5. So I believe the > description should remain unchanged. Makes sense, but for `error.no-wix-tools` I think we should add v5, in case if users sees this message when only v5 is installed. - PR Review Comment: https://git.openjdk.org/jdk/pull/19318#discussion_r1628308316
Re: RFR: 8319457: Update jpackage to support WiX v4 and v5 on Windows
On Tue, 4 Jun 2024 12:37:03 GMT, Alexey Semenyuk wrote: > > I assume WiX5 will just work if installed instead of WiX4? > > Correct. > > > Do you think it will make sense to introduce Wix5 ToolsetType in case if we > > need to do something different between 4 and 5? > > They claim WiX5 is backward compatible with WiX4, i.e. WiX4 code should work > with WiX5 toolkit. So I don't see a reason to introduce Wix5 ToolsetType now. jpackage allows override of main WiX source file (main.wxs), do you know what will happen if user will add main.wxs with format features available only in WiX 5 and will have WiX 5 toolkit installed? Do you know if there any benefits to use any features available in WiX5 if WiX5 toolkit is installed, instead of using only WiX4 features with WiX5 toolkit? - PR Comment: https://git.openjdk.org/jdk/pull/19318#issuecomment-2150809380
Re: RFR: 8325525: Create jtreg test case for JDK-8325203 [v2]
On Wed, 3 Jul 2024 04:11:40 GMT, Vanitha B P wrote:
>> Created jtreg test case for
>> [JDK-8325203](https://bugs.openjdk.org/browse/JDK-8325203) issue.
>>
>> The JpackageTest created tests that the child process started from the app
>> launched by jpackage launcher is not automatically terminated when the the
>> launcher is terminated.
>
> Vanitha B P has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 8325525 Addressed review comments
test/jdk/tools/jpackage/apps/ThirdPartyAppLauncher.java line 27:
> 25: import java.util.logging.Logger;
> 26:
> 27: public class ThirdPartyAppLauncher {
Maybe `ChildProcessAppLauncher` to match test name?
test/jdk/tools/jpackage/apps/ThirdPartyAppLauncher.java line 32:
> 30:
> 31: public static void main(String[] args) throws IOException {
> 32: ProcessBuilder processBuilder = new ProcessBuilder("regedit");
`regedit` will trigger elevation prompt if UAC is enabled, so this test will
not be able to run without user interaction. My suggestion is to use something
that does not requires elevation. For example: `calc.exe`. Also, use full path
to executable, otherwise it is not clear what will be run. I think
`System.getenv("SYSTEM")` should give path to `%WINDIR%\system32` where `calc`
is located.
test/jdk/tools/jpackage/share/JpackageTest.java line 51:
> 49: import jdk.jpackage.test.TKit;
> 50:
> 51: public class JpackageTest {
Can we put it under `test/jdk/tools/jpackage/windows`, since it is Windows only
test? Also, it needs better name. For example: `WinChildProcessTest`.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19536#discussion_r1664685484
PR Review Comment: https://git.openjdk.org/jdk/pull/19536#discussion_r1664702036
PR Review Comment: https://git.openjdk.org/jdk/pull/19536#discussion_r1664681991
Re: RFR: 8325525: Create jtreg test case for JDK-8325203 [v4]
On Tue, 9 Jul 2024 16:12:58 GMT, Vanitha B P wrote: >> Created jtreg test case for >> [JDK-8325203](https://bugs.openjdk.org/browse/JDK-8325203) issue. >> >> The JpackageTest created tests that the child process started from the app >> launched by jpackage launcher is not automatically terminated when the the >> launcher is terminated. > > Vanitha B P has updated the pull request incrementally with one additional > commit since the last revision: > > Addressed the review comment Looks good. - Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19536#pullrequestreview-2167519424
Re: RFR: 8336315: tools/jpackage/windows/WinChildProcessTest.java Failed: Check is calculator process is alive
On Wed, 24 Jul 2024 12:20:05 GMT, Vanitha B P wrote: > tools/jpackage/windows/WinChildProcessTest.java was failing intermittently, > fixed the issue and changes are tested. Looks good. I will approve once comments from Alexey are resolved. - PR Comment: https://git.openjdk.org/jdk/pull/20312#issuecomment-2248746951
Re: RFR: 8336315: tools/jpackage/windows/WinChildProcessTest.java Failed: Check is calculator process is alive [v2]
On Thu, 25 Jul 2024 08:40:44 GMT, Vanitha B P wrote: >> tools/jpackage/windows/WinChildProcessTest.java was failing intermittently, >> fixed the issue and changes are tested. > > Vanitha B P has updated the pull request incrementally with one additional > commit since the last revision: > > Addressed the review comments Marked as reviewed by almatvee (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/20312#pullrequestreview-2200371354
Re: [External] : Re: RFR: 8293462: [macos] app image signature invalid when creating DMG or PKG from post processed signed image
Hi Michael, It is not possible to provide a unique or hashed CFBundleIdentifier. We already implemented to throw error if —strip-native-commands are not provided to jlink or if provided runtime contain bin directory. Look at https://github.com/openjdk/jdk/pull/8666 Thanks, Alexander On Sep 27, 2022, at 4:44 AM, Michael Hall mailto:mik3h...@gmail.com>> wrote: On Sep 26, 2022, at 9:24 PM, Michael Hall mailto:mik3h...@gmail.com>> wrote: On Sep 20, 2022, at 5:50 PM, Michael Hall mailto:mik3h...@gmail.com>> wrote: Still you could use post-processing to add whatever java binary executable commands you wanted. This again would mean changes to the embedded jdk that might have signing side effects. I haven’t tested. Thinking about this I looked at my application that includes java commands and saw that currently I include all. And all appear to be of fixed size. So I assume some kind of launcher stub? I then remembered [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe https://bugs.openjdk.org/browse/JDK-8286122 It might be an idea, if coming up with a unique or hashed CFBundleIdentifier in the Info.plist isn’t seen as a workable alternative, for jpackage to issue a warning anytime jlink parameters are passed without —strip-native-commands to issue a warning message that the application will not be eligible for the Mac App Store. So developers don’t develop applications with a dependency on native commands intending them for the Mac App Store only to find out when they attempt a final MAS version that they are prohibited.
Re: RFR: 8293579: tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java fails on Japanese Windows platform [v2]
On Wed, 28 Sep 2022 09:45:32 GMT, KIRIYAMA Takuya wrote:
>> Could you please review the JDK-8293579 bug fixes?
>>
>> tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java attempts to
>> give
>> the launcher the character which is encoded by Windows API
>> WideCharToMultiByte()
>> from UNICODE "é"(0x00e9) as an argument. However, this test fails because
>> the
>> code point "é"(0x00e9) cannot be treated on Japanese Windows.
>>
>> WideCharToMultiByte() encodes characters as Shift-JIS on Japanese Windows,
>> but
>> the code point "é"(0x00e9) does not exist in Shift-JIS, and it is replaced
>> with
>> "e"(0x0065) as substitute. Therefore, "é"(0x00e9) and "e"(0x0065) are
>> compared
>> in this test and judged to be different characters, and return as failed.
>>
>> So, in the Japanese encoding("MS932", "SJIS"), the test should be modified
>> to
>> give a character such as "あ"(0x3042) as the launcher's argument instead of
>> "é"(0x00e9).
>
> KIRIYAMA Takuya has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8293579: tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java fails
> on Japanese Windows platform
Marked as reviewed by almatvee (Reviewer).
-
PR: https://git.openjdk.org/jdk/pull/10226
Re: Jpackage OS/X DMG install Application folder alias name incorrectly shows as path with /
Hi Michael,
If I understood correctly you asking for several things:
1) Change “/Applications” to “Applications”. I agree and we should fix it if
possible. Did you file a bug for it? If not I can file.
2) Resize DMG window to show additional content which was added via
--mac-dmg-content, so user does not have to scroll or manually resize window? I
think we can investigate this, but I think we still need to limit by how many
additional files we want to display in case if user adds for example 100 files
(very unlikely). Do you want to file enhancement for this? Or I can do it.
3) From your email "SceneBuilder OS/X DMG’s” do you mean provide ability to
localize “Applications” folder name? I think we can do this, but user will need
to produce separate localized DMG for each language.
Thanks,
Alexander
On Oct 30, 2022, at 2:42 PM, Michael Hall
mailto:mik3h...@gmail.com>> wrote:
On Oct 26, 2022, at 7:55 PM, Michael Hall
mailto:mik3h...@gmail.com>> wrote:
I was looking to see what any other dmg’s I have do to handle this. Not many
do. But those usually seem to use a smaller background image and icons.
I may look at that to see if I can manage something like that.
I made some changes that I think might address this. I tried to make the
changes as trivial as possible.
The only change to java is in MacDmgBundler.java, the prepareDMGSetupScript
method. I added…
List dmgContent = DMG_CONTENT.fetchFrom(params);
if (dmgContent.size() > 0) {
data.put("DEPLOY_ICON_SIZE", "64");
}
else {
data.put("DEPLOY_ICON_SIZE", "128");
}
I tried counting files in volumePath first but got a FileNotFoundException.
Possibly actually a privilege access error?
I obviously added DEPLOY_ICON_SIZE to the AppleScript and changed some spacing
and sizing. I wanted to be able to comfortably show up to four additional files
without scrolling.
I also put in something for /Applications. I simply hard coded it to
“Applications”. This seemed the most straight forward trivial way to do this.
Unless someone indicates where it is or might be something other than
Applications.
I put screenshots of the before and after DMG windows at
http://mikehall.pairserver.com/DMG_windows.dmg
The only after appearance drawback is extra white space at the bottom of the
application only window. This could be fairly easy to correct but isn’t really
that bad looking.
I appreciate the jpackage people implementing this feature and would appreciate
it if they consider this, essentially, cosmetic change.
Thanks.
I mentioned this on the javafx list indicating I had discovered you could use a
custom background image for the windows. I noticed in the verbose output today
that jpackage indicates it currently supports this feature with a correctly
named file in the resource directory. So doing anything external would be
unncecessary.
Re: [External] : Re: Jpackage OS/X DMG install Application folder alias name incorrectly shows as path with /
Hi Michael,
On Oct 31, 2022, at 2:40 PM, Michael Hall
mailto:mik3h...@gmail.com>> wrote:
On Oct 31, 2022, at 4:17 PM, Alexander Matveev
mailto:alexander.matv...@oracle.com>> wrote:
Hi Michael,
Hello Alexander,
If I understood correctly you asking for several things:
1) Change “/Applications” to “Applications”. I agree and we should fix it if
possible. Did you file a bug for it? If not I can file.
I thought I did but haven’t received a number yet.
I did not able to find a bug you filed, so filed a new one:
https://bugs.openjdk.org/browse/JDK-8296154
2) Resize DMG window to show additional content which was added via
--mac-dmg-content, so user does not have to scroll or manually resize window? I
think we can investigate this, but I think we still need to limit by how many
additional files we want to display in case if user adds for example 100 files
(very unlikely). Do you want to file enhancement for this? Or I can do it.
Not only resize the window but also the icons. It gives you a better appearance
than the current. I’m not sure you want to police the number of files, that
would be up the user. Usually I don’t think anyone is going to include anywhere
near that. I saw a few dmg’s on my machine that had two or three extra files.
I filed https://bugs.openjdk.org/browse/JDK-8296156 for this.
Thanks,
Alexander
3) From your email "SceneBuilder OS/X DMG’s” do you mean provide ability to
localize “Applications” folder name? I think we can do this, but user will need
to produce separate localized DMG for each language.
I don’t know that I had any responses indicating anyone is doing this or wants
it. I wasn’t sure if you already were doing any localizing. If not, I don’t
think its a current concern.
I already implemented changes for this. I signed the OCA so thought I might
attempt the update. No clue right now what that really involves. So with the
OCA signed you could probably just go ahead with my changes if you want?
I posted the change to MacDmgBundler in my prior. My changed DMGsetup.scpt is…
tell application "Finder"
set theDisk to a reference to (disks whose URL = "DEPLOY_VOLUME_URL")
open theDisk
set theWindow to a reference to (container window of disks whose URL =
"DEPLOY_VOLUME_URL")
set current view of theWindow to icon view
set toolbar visible of theWindow to false
set statusbar visible of theWindow to false
-- size of window should fit the size of background
set the bounds of theWindow to {400, 100, 920, 480}
set theViewOptions to a reference to the icon view options of theWindow
set arrangement of theViewOptions to not arranged
set icon size of theViewOptions to "DEPLOY_ICON_SIZE"
set background picture of theViewOptions to POSIX file "DEPLOY_BG_FILE"
-- Create alias for install location
make new alias file at POSIX file "DEPLOY_VOLUME_PATH" to POSIX file
"DEPLOY_INSTALL_LOCATION" with properties {name:"Applications"}
set allTheFiles to the name of every item of theWindow
set xpos to 120
repeat with theFile in allTheFiles
set theFilePath to POSIX path of theFile
set appFilePath to POSIX path of "/DEPLOY_TARGET"
if theFilePath is "DEPLOY_INSTALL_LOCATION" then
-- Position install location
set position of item theFile of theWindow to {390, 130}
else if theFilePath ends with appFilePath then
-- Position application or runtime
set position of item theFile of theWindow to {120, 130}
else
-- Position all other items in a second row.
set position of item theFile of theWindow to {xpos, 290}
set xpos to xpos + 95
end if
end repeat
update theDisk without registering applications
delay 5
close (get window of theDisk)
end tell
If you want to use that.
Re: [External] : Re: Jpackage OS/X DMG install Application folder alias name incorrectly shows as path with /
Hi Michael.
If you mean http://mikehall.pairserver.com/DMG_windows.dmg, then I cannot open
this link. It says file not found.
Thanks,
Alexander
On Oct 31, 2022, at 4:21 PM, Michael Hall
mailto:mik3h...@gmail.com>> wrote:
On Oct 31, 2022, at 5:56 PM, Alexander Matveev
mailto:alexander.matv...@oracle.com>> wrote:
Hi Michael,
On Oct 31, 2022, at 2:40 PM, Michael Hall
mailto:mik3h...@gmail.com>> wrote:
On Oct 31, 2022, at 4:17 PM, Alexander Matveev
mailto:alexander.matv...@oracle.com>> wrote:
Hi Michael,
Hello Alexander,
If I understood correctly you asking for several things:
1) Change “/Applications” to “Applications”. I agree and we should fix it if
possible. Did you file a bug for it? If not I can file.
I thought I did but haven’t received a number yet.
I did not able to find a bug you filed, so filed a new one:
https://bugs.openjdk.org/browse/JDK-8296154
Alexander,
OK thanks.
If you happen to look at the dmg with images I provided an URL for I think my
changes lay the added files out pretty well.
I think you definitely want to go with smaller icons. Apache OpenOffice has a
DMG I just found with a couple additional files that uses smaller icons.
I think this is a pretty normal thing to do.
Even with smaller icons I had to increase the window bottom parameter to get
them not to get chopped off.
set the bounds of theWindow to {400, 100, 920, 480}
That the last 480 in the above.
Given the smaller icons I also decreased to x coordinate increment. Made
fitting more files a little easier.
You can do this yourself but I think you will find doing similar works best.
Thanks,
Mike
RFR: 8296154: [macos] Change /Applications to Applications in DMG image
Changed names of symbolic links for drag and drop location in DMG image. See attached images in JBS. "/Applications" -> "Applications" for app DMG image. "/Library/Java/JavaVirtualMachines" -> "JavaVirtualMachines" for runtime DMG image. Automated test was not added, since DMGsetup.scpt is not getting executed in headless environment and thus symbolic links are not created during automated testing. - Commit messages: - 8296154: [macos] Change /Applications to Applications in DMG image Changes: https://git.openjdk.org/jdk/pull/11001/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11001&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296154 Stats: 28 lines in 3 files changed: 24 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/11001.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11001/head:pull/11001 PR: https://git.openjdk.org/jdk/pull/11001
Re: RFR: 8296154: [macos] Change "/Applications" to "Applications" in DMG image [v2]
> Changed names of symbolic links for drag and drop location in DMG image. See > attached images in JBS. > "/Applications" -> "Applications" for app DMG image. > "/Library/Java/JavaVirtualMachines" -> "JavaVirtualMachines" for runtime DMG > image. > > Automated test was not added, since DMGsetup.scpt is not getting executed in > headless environment and thus symbolic links are not created during automated > testing. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8296154: [macos] Change /Applications to Applications in DMG image [v2] - Changes: - all: https://git.openjdk.org/jdk/pull/11001/files - new: https://git.openjdk.org/jdk/pull/11001/files/df794aba..31690e08 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11001&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11001&range=00-01 Stats: 16 lines in 2 files changed: 0 ins; 9 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/11001.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11001/head:pull/11001 PR: https://git.openjdk.org/jdk/pull/11001
Re: RFR: 8296154: [macos] Change "/Applications" to "Applications" in DMG image [v2]
On Fri, 4 Nov 2022 23:44:15 GMT, Alexey Semenyuk wrote: >> Alexander Matveev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8296154: [macos] Change /Applications to Applications in DMG image [v2] > > src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBaseInstallerBundler.java > line 121: > >> 119: // use "Applications" or "JavaVirtualMachines". For user provided >> installation >> 120: // directory we will use full path as display name. >> 121: static String getInstallDirDisplayName( > > Is this method ever called with `false` as the last parameter? If no, I'd > remove it. No, it does not. I removed it. - PR: https://git.openjdk.org/jdk/pull/11001
Integrated: 8296154: [macos] Change "/Applications" to "Applications" in DMG image
On Fri, 4 Nov 2022 23:26:00 GMT, Alexander Matveev wrote: > Changed names of symbolic links for drag and drop location in DMG image. See > attached images in JBS. > "/Applications" -> "Applications" for app DMG image. > "/Library/Java/JavaVirtualMachines" -> "JavaVirtualMachines" for runtime DMG > image. > > Automated test was not added, since DMGsetup.scpt is not getting executed in > headless environment and thus symbolic links are not created during automated > testing. This pull request has now been integrated. Changeset: 7e85b41d Author:Alexander Matveev URL: https://git.openjdk.org/jdk/commit/7e85b41d37c5eec9693cfc07447f5deffd5d483b Stats: 19 lines in 3 files changed: 15 ins; 0 del; 4 mod 8296154: [macos] Change "/Applications" to "Applications" in DMG image Reviewed-by: asemenyuk - PR: https://git.openjdk.org/jdk/pull/11001
RFR: 8296156: [macos] Resize DMG windows and background to fit additional DMG contents
Additional DMG content will be arranged in raws with 3 items per raw. DMG windows will be resized to show one or two raws without any scrolling required. To see any additional content after two raws (7 or more items) user will need to use vertical scroll bar. See JBS for screen shots. - Commit messages: - 8296156: [macos] Resize DMG windows and background to fit additional DMG contents Changes: https://git.openjdk.org/jdk/pull/11068/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11068&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296156 Stats: 28 lines in 1 file changed: 25 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/11068.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11068/head:pull/11068 PR: https://git.openjdk.org/jdk/pull/11068
Integrated: 8296156: [macos] Resize DMG windows and background to fit additional DMG contents
On Wed, 9 Nov 2022 20:02:05 GMT, Alexander Matveev wrote: > Additional DMG content will be arranged in raws with 3 items per raw. DMG > windows will be resized to show one or two raws without any scrolling > required. To see any additional content after two raws (7 or more items) user > will need to use vertical scroll bar. See JBS for screen shots. This pull request has now been integrated. Changeset: 0981bfb1 Author: Alexander Matveev URL: https://git.openjdk.org/jdk/commit/0981bfb1a317466c095c392f82ddf6eae595f4af Stats: 28 lines in 1 file changed: 25 ins; 0 del; 3 mod 8296156: [macos] Resize DMG windows and background to fit additional DMG contents Reviewed-by: asemenyuk - PR: https://git.openjdk.org/jdk/pull/11068
Re: RFR: 8296489: tools/jpackage/windows/WinL10nTest.java fails with timeout
On Mon, 5 Dec 2022 22:20:19 GMT, Alexey Semenyuk wrote: > Simply increase timeout limit to make test pass on slower/loaded hosts Marked as reviewed by almatvee (Reviewer). - PR: https://git.openjdk.org/jdk/pull/11522
Re: RFR: 8293453: tools/jpackage/share/AddLShortcutTest.java "Failed: Check the number of mismatched pixels [1024] of [1024] is < [0.100000] threshold"
On Mon, 5 Dec 2022 22:14:50 GMT, Alexey Semenyuk wrote: > - throw an exception if icon swap fails with the corresponding l10n message; > - add retries to the jpackage test routine that extracts an icon from a > launcher Marked as reviewed by almatvee (Reviewer). - PR: https://git.openjdk.org/jdk/pull/11521
[jdk20] RFR: 8298488: [macos13] tools/jpackage tests failing with "Exit code: 137" on macOS
This issue is similar to JDK-8277493. Looks like macOS 13 cannot execute unsigned code and code should be at least ad hoc signed. Same as for macOS aarch64. Fixed by enabling ad hoc signing for macOS platform for both x64 and aarch64. - Commit messages: - 8298488: [macos13] tools/jpackage tests failing with "Exit code: 137" on macOS Changes: https://git.openjdk.org/jdk20/pull/20/files Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=20&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298488 Stats: 6 lines in 3 files changed: 0 ins; 4 del; 2 mod Patch: https://git.openjdk.org/jdk20/pull/20.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/20/head:pull/20 PR: https://git.openjdk.org/jdk20/pull/20
[jdk20] Integrated: 8298488: [macos13] tools/jpackage tests failing with "Exit code: 137" on macOS
On Mon, 12 Dec 2022 21:23:50 GMT, Alexander Matveev wrote: > This issue is similar to JDK-8277493. Looks like macOS 13 cannot execute > unsigned code and code should be at least ad hoc signed. Same as for macOS > aarch64. Fixed by enabling ad hoc signing for macOS platform for both x64 and > aarch64. This pull request has now been integrated. Changeset: 8962c723 Author: Alexander Matveev URL: https://git.openjdk.org/jdk20/commit/8962c723a8ae62a8638e9e0a89c20001aea1549a Stats: 6 lines in 3 files changed: 0 ins; 4 del; 2 mod 8298488: [macos13] tools/jpackage tests failing with "Exit code: 137" on macOS Reviewed-by: asemenyuk - PR: https://git.openjdk.org/jdk20/pull/20
Re: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v3]
On Thu, 15 Dec 2022 20:43:42 GMT, Damon Nguyen wrote:
>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Fix https and changed URL back
src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_de.properties
line 82:
> 80:
> 81: error.foreign-app-image=Fehler: .jpackage.xml-Datei fehlt in
> app-image-Verzeichnis ({0})
> 82: error.invalid-app-image=Fehler: app-image-Verzeichnis ({0}) wurde von
> einer anderen jpackage-Version generiert, oder .jpackage.xml ist nicht
> wohlgeformt
error.invalid-app-image looks like old translation and missing "{1}". Also, why
() is used instead of ""?
src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_ja.properties
line 82:
> 80:
> 81: error.foreign-app-image=\u30A8\u30E9\u30FC:
> app-image\u30C7\u30A3\u30EC\u30AF\u30C8\u30EA({0})\u306B.jpackage.xml\u30D5\u30A1\u30A4\u30EB\u304C\u3042\u308A\u307E\u305B\u3093
> 82: error.invalid-app-image=\u30A8\u30E9\u30FC:
> app-image\u30C7\u30A3\u30EC\u30AF\u30C8\u30EA({0})\u306F\u5225\u306Ejpackage\u30D0\u30FC\u30B8\u30E7\u30F3\u307E\u305F\u306F\u4E0D\u6B63\u306A.jpackage.xml\u3067\u751F\u6210\u3055\u308C\u307E\u3057\u305F
Same as "de" translation.
src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_zh_CN.properties
line 82:
> 80:
> 81: error.foreign-app-image=\u9519\u8BEF\uFF1Aapp-image \u76EE\u5F55 ({0})
> \u4E2D\u7F3A\u5C11 .jpackage.xml \u6587\u4EF6
> 82: error.invalid-app-image=\u9519\u8BEF\uFF1A\u53E6\u4E00\u4E2A jpackage
> \u7248\u672C\u6216\u683C\u5F0F\u9519\u8BEF\u7684 .jpackage.xml
> \u751F\u6210\u4E86 app-image \u76EE\u5F55 ({0})
Same as "de" translation.
src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_de.wxl
line 2:
> 1:
> 2: xmlns="http://schemas.microsoft.com/wix/2006/localization"; Codepage="1252">
Why "de-de" was changed to "de"?
src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_ja.wxl
line 2:
> 1:
> 2: xmlns="http://schemas.microsoft.com/wix/2006/localization"; Codepage="932">
Why "ja-jp" to "ja"?
src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_de.properties
line 37:
> 35: resource.post-app-image-script=Auszuf\u00FChrendes Skript nach dem
> Auff\u00FCllen des Anwendungsimages
> 36: resource.post-msi-script=Auszuf\u00FChrendes Skript nach dem Erstellen
> der MSI-Datei f\u00FCr das EXE-Installationsprogramm
> 37: resource.wxl-file-name=MsiInstallerStrings_en.wxl
Why this was changed?
src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_ja.properties
line 37:
> 35:
> resource.post-app-image-script=\u30A2\u30D7\u30EA\u30B1\u30FC\u30B7\u30E7\u30F3\u30FB\u30A4\u30E1\u30FC\u30B8\u3092\u79FB\u5165\u3057\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8
> 36:
> resource.post-msi-script=exe\u30A4\u30F3\u30B9\u30C8\u30FC\u30E9\u306Emsi\u30D5\u30A1\u30A4\u30EB\u304C\u4F5C\u6210\u3055\u308C\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8
> 37: resource.wxl-file-name=MsiInstallerStrings_en.wxl
Why this was changed?
src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_zh_CN.properties
line 37:
> 35:
> resource.post-app-image-script=\u8981\u5728\u586B\u5145\u5E94\u7528\u7A0B\u5E8F\u6620\u50CF\u4E4B\u540E\u8FD0\u884C\u7684\u811A\u672C
> 36: resource.post-msi-script=\u5728\u4E3A exe
> \u5B89\u88C5\u7A0B\u5E8F\u521B\u5EFA msi
> \u6587\u4EF6\u4E4B\u540E\u8981\u8FD0\u884C\u7684\u811A\u672C
> 37: resource.wxl-file-name=MsiInstallerStrings_en.wxl
Same as above.
-
PR: https://git.openjdk.org/jdk20/pull/35
Re: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v4]
On Thu, 15 Dec 2022 23:01:35 GMT, Damon Nguyen wrote:
>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Revert double quote as well
src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_ja.wxl
line 15:
> 13:Id="ShortcutPromptDlgStartMenuShortcutControlLabel">スタート・メニューのショートカットの作成
> 14: [ProductName]セットアップ
> 15: Open with [ProductName]
Why it was removed in all translations, except English?
src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_de.properties
line 51:
> 49: error.msi-product-version-minor-out-of-range=Nebenversion muss im Bereich
> [0, 255] liegen
> 50: error.version-swap=Versionsinformationen f\u00FCr {0} konnten nicht
> aktualisiert werden
> 51: error.icon-swap=Failed to update icon for {0}
Why this was removed?
-
PR: https://git.openjdk.org/jdk20/pull/35
Re: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v3]
On Fri, 16 Dec 2022 00:15:51 GMT, Damon Nguyen wrote:
>> src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_de.properties
>> line 82:
>>
>>> 80:
>>> 81: error.foreign-app-image=Fehler: .jpackage.xml-Datei fehlt in
>>> app-image-Verzeichnis ({0})
>>> 82: error.invalid-app-image=Fehler: app-image-Verzeichnis ({0}) wurde von
>>> einer anderen jpackage-Version generiert, oder .jpackage.xml ist nicht
>>> wohlgeformt
>>
>> error.invalid-app-image looks like old translation and missing "{1}". Also,
>> why () is used instead of ""?
>
> I'm not sure for the decisions of change in punctuation and for the missing
> {1} as I didn't do the translation myself. Would this be better to be
> reverted?
Looks like translation is done on files before JDK-8293462 was integrated
(before Sep 26). See
[commit](https://github.com/openjdk/jdk20/commit/1e222bccd3807c1be0d1d824e0ff9745751d8375#diff-8bfeb61c827c2bc073c65cbf4137dbf8f7baa5f4f88e5d59785e985d9510577c)
when I changed these two strings. For now it is better to revert them to
original English version or figure out why translation is old.
-
PR: https://git.openjdk.org/jdk20/pull/35
Re: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v3]
On Fri, 16 Dec 2022 00:24:26 GMT, Damon Nguyen wrote: >> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_ja.properties >> line 37: >> >>> 35: >>> resource.post-app-image-script=\u30A2\u30D7\u30EA\u30B1\u30FC\u30B7\u30E7\u30F3\u30FB\u30A4\u30E1\u30FC\u30B8\u3092\u79FB\u5165\u3057\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8 >>> 36: >>> resource.post-msi-script=exe\u30A4\u30F3\u30B9\u30C8\u30FC\u30E9\u306Emsi\u30D5\u30A1\u30A4\u30EB\u304C\u4F5C\u6210\u3055\u308C\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8 >>> 37: resource.wxl-file-name=MsiInstallerStrings_en.wxl >> >> Why this was changed? > > Also not sure as it is what I received from the latest translation drop. If > this is incorrect, I can manually correct this here and for the other locales > for this file. Yes it needs to be correct. It was changed to _ja, etc with [commit](https://github.com/openjdk/jdk20/commit/543163a03b5f1af7a7e7af317a26eb8c5aa81c38#diff-afb8ea68d8b3e9be4bba1c417c82d2162eea9333a3157f05ef57c026af94eb3b). Which was done on Aug 10, 2022, so it seems message drop is based on old code. - PR: https://git.openjdk.org/jdk20/pull/35
Re: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v5]
On Fri, 16 Dec 2022 03:38:54 GMT, Damon Nguyen wrote: >> Open l10n drop >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional > commit since the last revision: > > Revert old translation. Fix lang codes jpackage changes looks good. - Marked as reviewed by almatvee (Reviewer). PR: https://git.openjdk.org/jdk20/pull/35
Re: RFR: 8299278: tools/jpackage/share/AddLauncherTest.java#id1 failed AddLauncherTest.bug8230933
On Thu, 5 Jan 2023 20:10:45 GMT, Alexey Semenyuk wrote: > 8299278: tools/jpackage/share/AddLauncherTest.java#id1 failed > AddLauncherTest.bug8230933 Marked as reviewed by almatvee (Reviewer). - PR: https://git.openjdk.org/jdk/pull/11868
Re: RFR: 8298735: Some tools/jpackage/windows/* tests fails with jtreg test timeout
On Mon, 9 Jan 2023 22:53:18 GMT, Alexey Semenyuk wrote: > Increase failed test timeouts. > Simple tests got an x1.5 increase and parametrized tests got an x2 increase Marked as reviewed by almatvee (Reviewer). - PR: https://git.openjdk.org/jdk/pull/11914
RFR: 8299779: Test tools/jpackage/share/jdk/jpackage/tests/MainClassTest.java timed out
- Fixed by increasing test timeout. Fix verified on host which reproduced issue. - Commit messages: - 8299779: Test tools/jpackage/share/jdk/jpackage/tests/MainClassTest.java timed out Changes: https://git.openjdk.org/jdk/pull/12896/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12896&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299779 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12896.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12896/head:pull/12896 PR: https://git.openjdk.org/jdk/pull/12896
Integrated: 8299779: Test tools/jpackage/share/jdk/jpackage/tests/MainClassTest.java timed out
On Tue, 7 Mar 2023 00:56:02 GMT, Alexander Matveev wrote: > - Fixed by increasing test timeout. Fix verified on host which reproduced > issue. This pull request has now been integrated. Changeset: 0a4d54f7 Author:Alexander Matveev URL: https://git.openjdk.org/jdk/commit/0a4d54f7ce2ac906a8012ed92c84ed8303cb4b90 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8299779: Test tools/jpackage/share/jdk/jpackage/tests/MainClassTest.java timed out Reviewed-by: asemenyuk - PR: https://git.openjdk.org/jdk/pull/12896
Re: RFR: JDK-8304063: tools/jpackage/share/AppLauncherEnvTest.java fails when checking LD_LIBRARY_PATH [v2]
On Thu, 16 Mar 2023 09:08:08 GMT, Matthias Baesken wrote: >> The test fails on Alpine Linux 3.17, when checking the environment variable >> LD_LIBRARY_PATH; looks like the actual env variable is much longer than the >> test expects. It turned out that at least on Linux (probably also on other >> OS like AIX) the actual env variable has the expected string at it's end, >> but might contain more path entries ( LD_LIBRARY_PATH can be adjusted by jvm >> - >> https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libjli/java_md.c >> ). > > Matthias Baesken has updated the pull request incrementally with one > additional commit since the last revision: > > redo check Marked as reviewed by almatvee (Reviewer). - PR: https://git.openjdk.org/jdk/pull/13041
RFR: 8298995: tools/jpackage/share/AddLauncherTest.java#id1 failed "AddLauncherTest.test; checks=53"
This is similar to many other issues we had with `hdiutil` failures. Fixed in similar way by repeating `hdiutil` command. Cannot confirm that it will resolve this issue, but similar issues got resolved by repeating command. Also, switched writing output from `hdiutil` to file. It is known issue that execution of `hdiutil` can hang if output is not written to file. - Commit messages: - 8298995: tools/jpackage/share/AddLauncherTest.java#id1 failed "AddLauncherTest.test; checks=53" Changes: https://git.openjdk.org/jdk/pull/13002/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13002&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298995 Stats: 49 lines in 2 files changed: 31 ins; 0 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/13002.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13002/head:pull/13002 PR: https://git.openjdk.org/jdk/pull/13002
Integrated: 8298995: tools/jpackage/share/AddLauncherTest.java#id1 failed "AddLauncherTest.test; checks=53"
On Mon, 13 Mar 2023 16:50:51 GMT, Alexander Matveev wrote: > This is similar to many other issues we had with `hdiutil` failures. Fixed in > similar way by repeating `hdiutil` command. Cannot confirm that it will > resolve this issue, but similar issues got resolved by repeating command. > Also, switched writing output from `hdiutil` to file. It is known issue that > execution of `hdiutil` can hang if output is not written to file. This pull request has now been integrated. Changeset: c56f011b Author:Alexander Matveev URL: https://git.openjdk.org/jdk/commit/c56f011baa4ce7f44661f6ade8e313f812730c02 Stats: 49 lines in 2 files changed: 31 ins; 0 del; 18 mod 8298995: tools/jpackage/share/AddLauncherTest.java#id1 failed "AddLauncherTest.test; checks=53" Reviewed-by: asemenyuk - PR: https://git.openjdk.org/jdk/pull/13002
Re: RFR: 8294806: jpackaged-app ignores splash screen from jar file
On Mon, 10 Apr 2023 21:16:19 GMT, Alexey Semenyuk wrote: > When `--main-jar` is specified and the name of the main class is picked from > the jar's manifest, set `app.jarfile` property in launcher cfg file instead > of `app.mainclass` and `app.classpath` properties to make app launcher run > the app from the jar and not as a class from the classpath. Looks good. - Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13413#pullrequestreview-1378179729
Re: RFR: 8304914: Use OperatingSystem, Architecture, and Version in jpackage [v2]
On Fri, 5 May 2023 14:12:21 GMT, Roger Riggs wrote:
>> Refactor the Platform class in jdk.jpackage to use the internal
>> OperatingSystem, Architecture, and Version classes.
>> The OperatingSystem.isXXX() and Architecture.isYYY() methods replace
>> comparisons in the Platform class.
>> The checks of the os.version are replaced but may not be needed if OpenJDK
>> no longer supports them.
>>
>> It is recommended to remove os version checks that apply only to Mac
>> versions before 10.15.
>> Mac OS X 10.15 is the oldest version supported.
>
> Roger Riggs has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Minor source code style cleanup
src/jdk.jpackage/share/classes/jdk/jpackage/internal/CLIHelp.java line 51:
> 49: Log.info(I18N.getString("MSG_Help_no_args"));
> 50: } else {
> 51: OperatingSystem platform = OperatingSystem.current();
Should we add if (Log.isVerbose) back? Otherwise default case in switch
statement never executed.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/13586#discussion_r1192826773
Re: RFR: 8304914: Use OperatingSystem, Architecture, and Version in jpackage [v2]
On Mon, 15 May 2023 20:10:38 GMT, Roger Riggs wrote:
>> src/jdk.jpackage/share/classes/jdk/jpackage/internal/CLIHelp.java line 51:
>>
>>> 49: Log.info(I18N.getString("MSG_Help_no_args"));
>>> 50: } else {
>>> 51: OperatingSystem platform = OperatingSystem.current();
>>
>> Should we add if (Log.isVerbose) back? Otherwise default case in switch
>> statement never executed.
>
> I was puzzled by that check early on and its still a puzzle. It seems a bit
> of a hack overloaded on the platform dispatch.
> As it turns out, the only time that `Log.isVerbose()` is true when
> `showHelp()` is called is when the environment variable `JPACKAGE_DEBUG` is
> used for debugging.
> `showHelp()` is only called before argument parsing is done and it doesn't
> look for --verbose. See `Main.execute()`
> So checking for isVerbose has no practical function.
Makes sense. Looks good.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/13586#discussion_r1198309008
Re: RFR: 8304914: Use OperatingSystem, Architecture, and Version in jpackage [v3]
On Mon, 15 May 2023 22:51:52 GMT, Roger Riggs wrote:
>> Refactor the Platform class in jdk.jpackage to use the internal
>> OperatingSystem, Architecture, and Version classes.
>> The OperatingSystem.isXXX() and Architecture.isYYY() methods replace
>> comparisons in the Platform class.
>> The checks of the os.version are replaced but may not be needed if OpenJDK
>> no longer supports them.
>>
>> It is recommended to remove os version checks that apply only to Mac
>> versions before 10.15.
>> Mac OS X 10.15 is the oldest version supported.
>
> Roger Riggs has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains 34 commits:
>
> - Merge branch 'master' into 8304914-os-jpackage
> - The OperatingSystem enum treats AIX separately from Linux. The original
> Platform used the same enum for both.
>Whereever OperatingSystem.isLinux is used in jpackage it should include
> isAix as well.
> - Minor source code style cleanup
> - Merge branch 'master' into 8304914-os-jpackage
> - Merge branch '8306678-os-version' into 8304914-os-jpackage
> - Merge branch '8304915-arch-enum' into 8306678-os-version
> - Correct comment on isPPC64() and refer to isLittleEndian() instead of
> mentioning PPC64LE
> - Simplify initialization in ClassLoaderHelper and fix VersionTest.
> - Revert changes to MacOsX sun.nio.fs.BsdFileStore; the version check is
> being removed in another PR.
> - Review comment updates
> - ... and 24 more: https://git.openjdk.org/jdk/compare/7b0b9b57...64ab7126
Based on jpackage Platform.java we defined Linux as `os.indexOf("nix") >= 0 ||
os.indexOf("nux") >= 0`, I might be wrong but I think it will not detect AIX in
original implementation. Do you know why it is added to jpackage? Also, did we
test jpackage on AIX system?
-
PR Comment: https://git.openjdk.org/jdk/pull/13586#issuecomment-1553665336
Re: RFR: 8287971: Throw exception for missing values in .jpackage.xml [v2]
> - 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://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9098__;!!ACWV5N9M2RV99hQ!NgVdVIfGfiCL40KAsDby-Ir9nDaz-bobTPkIIqXNrWDeLTm0q-Z69dZ98EP_SNaNq4XEfm_LtGBAUzlzYWY5RAtroQ$ > . Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8287971: Throw exception for missing values in .jpackage.xml [v2] - Changes: - all: https://git.openjdk.org/jdk19/pull/9/files - new: https://git.openjdk.org/jdk19/pull/9/files/daee617b..c06af061 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=9&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=9&range=00-01 Stats: 250 lines in 9 files changed: 159 ins; 54 del; 37 mod Patch: https://git.openjdk.org/jdk19/pull/9.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/9/head:pull/9 PR: https://git.openjdk.org/jdk19/pull/9
Re: RFR: 8287971: Throw exception for missing values in .jpackage.xml [v2]
On Tue, 14 Jun 2022 18:07:12 GMT, Alexey Semenyuk wrote:
>> Alexander Matveev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8287971: Throw exception for missing values in .jpackage.xml [v2]
>
> 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?
To store string values, so it can be validated to make sure it is true or false
only. I changed it back, since I moved validation to ctor.
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageFile.java line
> 339:
>
>> 337: !("true".equals(appStoreStr) ||
>> "false".equals(appStoreStr))) {
>> 338: return false;
>> 339: }
>
> It makes sense to unfold this function in the ctor as we don't allow empty
> AppImageFile instances.
Done.
> 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})."
Done.
> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TKit.java line 272:
>
>> 270: ));
>> 271: }
>> 272:
>
> 1. This is jpackage specific, so it should belong to JPackageCommand class.
> 2. Please use proper XML API to create XML output.
> 3. Having `1.0` in .jpackage.xml file will make
> `AppImageFile.isValid()` return `false` and `AppImageFile.load()` to throw
> exception. This seems to be equivalent to not having .jpackage.xml file in
> app image at all raising a question if this new function is needed at all.
1 and 2 done. I think you mistaken `1.0` with
` and I do put
correct value for `https://git.openjdk.org/jdk19/pull/9
Re: RFR: 8287401: jpackage tests failing on Windows due to powershell issue
On Thu, 16 Jun 2022 05:15:27 GMT, Alexey Semenyuk wrote: > Run a script extracting icons from executables as PowerShell command line > rather than a script Marked as reviewed by almatvee (Reviewer). - PR: https://git.openjdk.org/jdk19/pull/26
Re: RFR: 8287971: Throw exception for missing values in .jpackage.xml [v3]
> - 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://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9098__;!!ACWV5N9M2RV99hQ!O9EYpCECe4owBSx5Afed1_edIOYL5-MqdziwEb_3iNi3T8oFSoldnyr3Gbz_8xPC-of21OjvRc3oLJ-J5w6V0Lpkng$ > . Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8287971: Throw exception for missing values in .jpackage.xml [v3] - Changes: - all: https://git.openjdk.org/jdk19/pull/9/files - new: https://git.openjdk.org/jdk19/pull/9/files/c06af061..2199f4e2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=9&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=9&range=01-02 Stats: 99 lines in 2 files changed: 1 ins; 97 del; 1 mod Patch: https://git.openjdk.org/jdk19/pull/9.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/9/head:pull/9 PR: https://git.openjdk.org/jdk19/pull/9
Re: RFR: 8287971: Throw exception for missing values in .jpackage.xml [v2]
On Thu, 16 Jun 2022 18:21:02 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://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9098__;!!ACWV5N9M2RV99hQ!MiXPcE28nIXl_Hg-ji0E1JDSYIL3xYaIfIUBzeIpboB3rr5cYRxY-XwVKLB0tbQTs6ifthtrkSwAWeh6ssIYexxC1g$ >> . > > Alexander Matveev has updated the pull request incrementally with one > additional commit since the last revision: > > 8287971: Throw exception for missing values in .jpackage.xml [v2] 8287971: Throw exception for missing values in .jpackage.xml [v3] - Removed copy/paste code from TKit.java. - PR: https://git.openjdk.org/jdk19/pull/9
Re: RFR: 8287971: Throw exception for missing values in .jpackage.xml [v4]
> - 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://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9098__;!!ACWV5N9M2RV99hQ!LN6NRTeW0ncedaBw8wNkDvWsY7haMeJTzuSC4dsP1nBOzWYLKB3-vd2Kai_PP_xq482TZ8ZfXiUEmg2xwSLTYQF3Bw$ > . Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8287971: Throw exception for missing values in .jpackage.xml [v4] - Changes: - all: https://git.openjdk.org/jdk19/pull/9/files - new: https://git.openjdk.org/jdk19/pull/9/files/2199f4e2..d489ee60 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=9&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=9&range=02-03 Stats: 25 lines in 2 files changed: 0 ins; 15 del; 10 mod Patch: https://git.openjdk.org/jdk19/pull/9.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/9/head:pull/9 PR: https://git.openjdk.org/jdk19/pull/9
Re: RFR: 8287971: Throw exception for missing values in .jpackage.xml [v3]
On Fri, 17 Jun 2022 17:01:10 GMT, Alexey Semenyuk wrote:
>> Alexander Matveev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8287971: Throw exception for missing values in .jpackage.xml [v3]
>
> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java line
> 307:
>
>> 305: if (appImage == null) {
>> 306: throw new RuntimeException("Error: --app-image expected");
>> 307: }
>
> Can be simplified to:
>
> Path jpackageXMLFile = AppImageFile.getPathInAppImage(
> Optional.ofNullable(getArgumentValue("--app-image")).map(
> Path::of).orElseThrow(() -> {
> return new RuntimeException(
> "Error: --app-image expected");
> }));
>
>
> And you don't need copy/paste code from `AppImageFile.getPathInAppImage()`
> below.
Done. I also switched to use AppImageFile.getVersion() and
AppImageFile.getPlatform().
-
PR: https://git.openjdk.org/jdk19/pull/9
Integrated: 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://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9098__;!!ACWV5N9M2RV99hQ!MCPPHJCD6t-Japw98nbgIUCpUdM03Z6WDLlmGq6mT87cGQ31fpSgwcvIJwM7-dHEgrXUuQYej_UD5bWVI3a6r1MKgw$ > . This pull request has now been integrated. Changeset: 70008da6 Author:Alexander Matveev URL: https://git.openjdk.org/jdk19/commit/70008da6b47c371c4d15162ca38e1521cd09acf9 Stats: 207 lines in 11 files changed: 96 ins; 76 del; 35 mod 8287971: Throw exception for missing values in .jpackage.xml Reviewed-by: asemenyuk - PR: https://git.openjdk.org/jdk19/pull/9
Re: [External] : Re: RFR: 8286850: [macos] Add support for signing user provided app image [v2]
Hi Michael, Did you modified app image after it was signed and before DMG was created? If yes, it is expected behavior and we will not sign app image when generating DMG. Can you provide all steps you did to get to issue below? Thanks, Alexander > On Jun 22, 2022, at 1:51 PM, Michael Hall wrote: > > Alexander, > > Sorry yet again. I really should have totally completed. While the > application verified on disk immediately after signing. The dmg version does > not appear to verify. > > codesign -v --verbose=4 /Applications/BlackJack\ Blastoff_Unsigned.app > /Applications/BlackJack Blastoff_Unsigned.app: a sealed resource is missing > or invalid > file added: /Applications/BlackJack > Blastoff_Unsigned.app/Contents/app/.package > file modified: /Applications/BlackJack > Blastoff_Unsigned.app/Contents/runtime/Contents/Home/legal/java.management.rmi/LICENSE > … > A lot of those > … > file missing: /Applications/BlackJack > Blastoff_Unsigned.app/Contents/app/.jpackage.xml > > Same result checking while still in the mounted dmg or copied into > /Applications > > Should this be working? > > java --version > openjdk 19-ea 2022-09-20 > OpenJDK Runtime Environment (build 19-ea+27-2074) > OpenJDK 64-Bit Server VM (build 19-ea+27-2074, mixed mode, sharing) > > Or should I bug report? > > Mike > > (Fwiw I remember this same signing issue from an earlier release - I could > probably track down the bug report.) > > >
Re: [External] : Re: RFR: 8286850: [macos] Add support for signing user provided app image [v2]
Hi Michael, I was able to reproduce it. Not sure what is wrong. Do you want to file a bug for this? Or I can file one myself. Thanks, Alexander > On Jun 22, 2022, at 5:22 PM, Michael Hall wrote: > > > >> On Jun 22, 2022, at 7:15 PM, Michael Hall wrote: >> >> >> >>> On Jun 22, 2022, at 6:57 PM, Alexander Matveev >>> wrote: >>> >>> Hi Michael, >>> >>> Did you modified app image after it was signed and before DMG was created? >>> If yes, it is expected behavior and we will not sign app image when >>> generating DMG. >>> >>> Can you provide all steps you did to get to issue below? >>> >>> Thanks, >>> Alexander >>> >> Alexander, >> >> They were pretty much as shown. >> 1). Create with script shown. >> verify with previously shown error >> 2). Sign as per your post >> verify showed good >> 3). DMG as previously shown >> DMG created and opens >> Reported good >> Did verify against mounted dmg, got errors shown >> Copied to Applications directory, got errors shown. >> >> No changes to application image or dmg done at any point. Nothing except >> codesign verifies. >> >> Prior bug with same error appears to have not had a resolution. I wasn’t >> depending on successful code signing at the time I don’t think. >> JDK-8263156 : [macos]: OS X application signing concerns - a sealed resource >> is missing or invalid >> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263156 >> >> The three steps to create - sign - dmg should be pretty easy to reproduce >> with a test app. >> >> Mike >> > That may of been when I was doing an incorrect copy to a test directory using > ‘cp’. I had some errors that corrected when I switched to the OS/X ‘ditto’ > command. > How are you copying to the dmg for step 3? Possibly something happens there? >
Re: [External] : Re: RFR: 8286850: [macos] Add support for signing user provided app image [v2]
Hi Michael, I filed it as https://bugs.openjdk.org/browse/JDK-8289030 Thanks, Alexander On Jun 22, 2022, at 5:40 PM, Michael Hall mailto:mik3h...@gmail.com>> wrote: On Jun 22, 2022, at 7:36 PM, Alexander Matveev mailto:alexander.matv...@oracle.com>> wrote: Hi Michael, I was able to reproduce it. Not sure what is wrong. Do you want to file a bug for this? Or I can file one myself. Thanks, Alexander You can get it. I have no immediate need again. Just thought I might post an example of how it could be used to customize an Info.plist. Maybe indicate the number so I can track it. Thanks for the follow up. Mike
Re: RFR: 8288961: jpackage: test MSI installation fix
On Wed, 22 Jun 2022 11:53:39 GMT, Alex Kasko wrote: > Please review this minor fix to the jpackage test suite. > > When `INSTALL` and `UNINSTALL` actions are enabled for jpackage test suite > runs (disabled by default), installation of `EXE` and `MSI` packages is > performed. `EXE` package is invoked directly and `MSI` package is installed > using `msiexec` utility. In both cases the path of the packages starts with a > "." (current dir) symbol, it is processed correctly with EXE installation, > but not with MSI, example: > > > [03:52:19.634] TRACE: assertTrue(): Check > [.\\test.bcc14973\\output\\FileAssociationsTest-1.0.msi] path exists > [03:52:19.634] TRACE: assertTrue(): Check > [.\\test.bcc14973\\output\\FileAssociationsTest-1.0.msi] is a file > [03:52:19.634] TRACE: exec: Execute [msiexec /qn /norestart /i > .\\test.bcc14973\\output\\FileAssociationsTest-1.0.msi](5); discard I/O... > [03:52:19.790] TRACE: exec: Done. Exit code: 1619 > [03:52:19.805] ERROR: Expected [0]. Actual [1619]: Check command [msiexec /qn > /norestart /i .\\test.bcc14973\\output\\FileAssociationsTest-1.0.msi](5) > exited with 0 code > > > Is is proposed to normalize the path passed to `msiexec`, in this case > installation will succeed: > > > [03:56:52.429] TRACE: assertTrue(): Check > [.\\test.bcc14973\\output\\FileAssociationsTest-1.0.msi] path exists > [03:56:52.429] TRACE: assertTrue(): Check > [.\\test.bcc14973\\output\\FileAssociationsTest-1.0.msi] is a file > [03:56:52.429] TRACE: exec: Execute [msiexec /qn /norestart /i > test.bcc14973\\output\\FileAssociationsTest-1.0.msi](5); discard I/O... > [03:56:57.067] TRACE: exec: Done. Exit code: 0 > [03:56:57.067] TRACE: assertEquals(0): Check command [msiexec /qn /norestart > /i test.bcc14973\\output\\FileAssociationsTest-1.0.msi](5) exited with 0 code Marked as reviewed by almatvee (Reviewer). - PR: https://git.openjdk.org/jdk/pull/9236
Re: RFR: 8288013: jpackage: test utility Windows registry enhancement
On Wed, 8 Jun 2022 11:46:42 GMT, Alex Kasko wrote: > In jpackage test suite there is a test utility > WindowsHelper.queryRegistryValue . It is used to verify changes to Windows > registry that can be done by installer packages. It spawns `reg.exe query` > process and parses its output. This patch adds support for quering empty > values and additional REG_* datatypes. > > Correctness was verified manually with the following registry values: > > > //(Default)REG_SZtest1 > //string_valREG_SZtest2 > //string_val_emptyREG_SZ > //bin_valREG_BINARY4242 > //bin_val_emptyREG_BINARY > //dword_valREG_DWORD0x2a > //qword_valREG_QWORD0x2a > //multi_string_valREG_MULTI_SZtest3\0test4 > //multi_string_val_emptyREG_MULTI_SZ > //expand_string_valREG_EXPAND_SZtest5 > //expand_string_val_emptyREG_EXPAND_SZ > > > Corresponding utility output: > > > [04:36:38.190] TRACE: Registry value [] at [...] path is [test1] > [04:36:38.220] TRACE: Registry value [string_val] at [...] path is [test2] > [04:36:38.251] TRACE: Registry value [string_val_empty] at [...] path is [] > [04:36:38.282] TRACE: Registry value [bin_val] at [...] path is [4242] > [04:36:38.315] TRACE: Registry value [bin_val_empty] at [...] path is [] > [04:36:38.347] TRACE: Registry value [dword_val] at [...] path is [0x2a] > [04:36:38.378] TRACE: Registry value [qword_val] at [...] path is [0x2a] > [04:36:38.410] TRACE: Registry value [multi_string_val] at [...] path is > [test3\\0test4] > [04:36:38.441] TRACE: Registry value [multi_string_val_empty] at [...] path > is [] > [04:36:38.473] TRACE: Registry value [expand_string_val] at [...] path is > [test5] > [04:36:38.506] TRACE: Registry value [expand_string_val_empty] at [...] path > is [] > > > Testing: > > - [x] ran "jtreg:jdk/tools/jpackage/windows" before and after the patch Marked as reviewed by almatvee (Reviewer). - PR: https://git.openjdk.org/jdk/pull/9083
[jdk19] RFR: 8289030: [macos] app image signature invalid when creating DMG or PKG
Fixed 3 issues which made signature invalid: - We should not remove .jpackage.xml from signed app image when creating DMG or PKG otherwise it invalidates signature. - .package should be created when app image is generated, so this file can be signed. - Copying predefine app image for DMG and PKG should not follow symbolic links, otherwise several files from runtime (COPYRIGHT and LICENSE) will be copied instead of symbolic links being created, since it invalidates signature as well. Added additional test to validate signature when DMG or PKG is generated from predefined app image. - Commit messages: - 8289030: [macos] app image signature invalid when creating DMG or PKG Changes: https://git.openjdk.org/jdk19/pull/89/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=89&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289030 Stats: 149 lines in 5 files changed: 134 ins; 6 del; 9 mod Patch: https://git.openjdk.org/jdk19/pull/89.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/89/head:pull/89 PR: https://git.openjdk.org/jdk19/pull/89
Re: [jdk19] RFR: 8289030: [macos] app image signature invalid when creating DMG or PKG
On Wed, 29 Jun 2022 03:03:15 GMT, Alexander Matveev wrote: > Fixed 3 issues which made signature invalid: > - We should not remove .jpackage.xml from signed app image when creating DMG > or PKG otherwise it invalidates signature. > - .package should be created when app image is generated, so this file can be > signed. > - Copying predefine app image for DMG and PKG should not follow symbolic > links, otherwise several files from runtime (COPYRIGHT and LICENSE) will be > copied instead of symbolic links being created, since it invalidates > signature as well. > > Added additional test to validate signature when DMG or PKG is generated from > predefined app image. 8289030: [macos] app image signature invalid when creating DMG or PKG [v2] - Fixed as suggested by Alexey. If app image already signed we will not add `.package` file. - PR: https://git.openjdk.org/jdk19/pull/89
Re: [jdk19] RFR: 8289030: [macos] app image signature invalid when creating DMG or PKG [v2]
> Fixed 3 issues which made signature invalid: > - We should not remove .jpackage.xml from signed app image when creating DMG > or PKG otherwise it invalidates signature. > - .package should be created when app image is generated, so this file can be > signed. > - Copying predefine app image for DMG and PKG should not follow symbolic > links, otherwise several files from runtime (COPYRIGHT and LICENSE) will be > copied instead of symbolic links being created, since it invalidates > signature as well. > > Added additional test to validate signature when DMG or PKG is generated from > predefined app image. Alexander Matveev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into JDK-8289030 - 8289030: [macos] app image signature invalid when creating DMG or PKG [v2] - 8289030: [macos] app image signature invalid when creating DMG or PKG - Changes: - all: https://git.openjdk.org/jdk19/pull/89/files - new: https://git.openjdk.org/jdk19/pull/89/files/5e47a1e3..4d5d4bce Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=89&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=89&range=00-01 Stats: 1986 lines in 64 files changed: 1671 ins; 95 del; 220 mod Patch: https://git.openjdk.org/jdk19/pull/89.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/89/head:pull/89 PR: https://git.openjdk.org/jdk19/pull/89
Re: RFR: 8288838: jpackage: file association additional arguments [v4]
On Mon, 4 Jul 2022 23:38:08 GMT, Alex Kasko wrote: >> jpackage implementation of file association on Windows currently passes a >> selected filename as an only argument to associated executable. >> >> It is proposed to introduce additional option in file association property >> file to allow optionally support additional arguments using `%*` batch >> wildcard. >> >> Note, current implementation, while fully functional, is only a **DRAFT** >> one, it is not ready for integration in this form. I would appreciate any >> guidance on the following points: >> >> - option naming inside a properties file, currently `pass-all-args` is used >> - option naming in a bundler parameter implementation, it is not clear if >> it should introduce a new group of "file association windows specific >> options" next to the existing "file association mac specific options" group >> - test organization to cover the new option: currently it is included >> inside `FileAssociationTest` and piggybacks on the existing (and unrelated) >> `includeDescription` parameter; it is not clear whether it should be done in >> a separate test and whether to include runs for every parameter combination >> - test run implementation: currently arguments are checked when a file with >> associated extension is invoked from command line; it is not clear whether >> it would be more appropriate instead to create a desktop shortcut with the >> same command as a target and to invoke it with `java.awt.Desktop` >> >> Also please note, that full install/uninstall run is currently enabled in >> `FileAssociationTest`, it is intended to be used only in a draft code during >> the development and to be removed (to use the same "install or unpack" logic >> as other tests) in a final version. >> >> Testing: >> >> - [x] test to cover new logic is included >> - [x] ran jtreg:jdk/tools/jpackage with no new failures > > Alex Kasko has updated the pull request with a new target base due to a merge > or a rebase. The pull request now contains three commits: > > - enable passing args, add test coverage > - Added input params validation > - Proposed test changes to make FA testing of jpackage more flexible Marked as reviewed by almatvee (Reviewer). - PR: https://git.openjdk.org/jdk/pull/9224
Re: [jdk19] RFR: 8289030: [macos] app image signature invalid when creating DMG or PKG [v2]
On Thu, 7 Jul 2022 17:07:51 GMT, Alexey Semenyuk wrote:
>> Alexander Matveev has updated the pull request with a new target base due to
>> a merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains three additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'upstream/master' into JDK-8289030
>> - 8289030: [macos] app image signature invalid when creating DMG or PKG [v2]
>> - 8289030: [macos] app image signature invalid when creating DMG or PKG
>
> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBaseInstallerBundler.java
> line 171:
>
>> 169:Files.deleteIfExists(AppImageFile.getPathInAppImage(appDir));
>> 170: }
>> 171:
>
> I think there is no need to modify AbstractAppImageBuilder.java, and
> AppImageBundler.java.
> It is sufficient to modify the condition controlling the creation of
> `.package` file:
>
> if (predefinedImage == null ||
> (!StandardBundlerParam.isRuntimeInstaller(params) &&
> !AppImageFile.load(predefinedImage).isSigned())) {
> new PackageFile(APP_NAME.fetchFrom(params)).save(
> ApplicationLayout.macAppImage().resolveAt(appDir));
> Files.deleteIfExists(AppImageFile.getPathInAppImage(appDir));
> }
>
> Besides `.package` file logically doesn't belong to app image, it belongs to
> the installed application, so it must not be referenced from the classes
> creating app images.
We need to add `.package` file during app image creation, since we need to sign
it. With your proposed change we will add `.package` file to already signed app
image.
-
PR: https://git.openjdk.org/jdk19/pull/89
Re: [jdk19] RFR: 8289030: [macos] app image signature invalid when creating DMG or PKG [v2]
On Thu, 7 Jul 2022 17:11:23 GMT, Alexey Semenyuk wrote:
>> Alexander Matveev has updated the pull request with a new target base due to
>> a merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains three additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'upstream/master' into JDK-8289030
>> - 8289030: [macos] app image signature invalid when creating DMG or PKG [v2]
>> - 8289030: [macos] app image signature invalid when creating DMG or PKG
>
> test/jdk/tools/jpackage/macosx/SigningPackageTwoStepTest.java line 87:
>
>> 85: private static void verifyAppImageInDMG(JPackageCommand cmd) {
>> 86: MacHelper.withExplodedDmg(cmd, dmgImage -> {
>> 87: Path launcherPath = dmgImage.resolve(Path.of("Contents",
>> "MacOS", cmd.name()));
>
> I'd replace it with
> `ApplicationLayout.macAppImage().resolveAt(dmgImage).launchersDirectory(cmd.name())`
Fixed.
-
PR: https://git.openjdk.org/jdk19/pull/89
Re: [jdk19] RFR: 8289030: [macos] app image signature invalid when creating DMG or PKG [v3]
> Fixed 3 issues which made signature invalid: > - We should not remove .jpackage.xml from signed app image when creating DMG > or PKG otherwise it invalidates signature. > - .package should be created when app image is generated, so this file can be > signed. > - Copying predefine app image for DMG and PKG should not follow symbolic > links, otherwise several files from runtime (COPYRIGHT and LICENSE) will be > copied instead of symbolic links being created, since it invalidates > signature as well. > > Added additional test to validate signature when DMG or PKG is generated from > predefined app image. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8289030: [macos] app image signature invalid when creating DMG or PKG [v3] - Changes: - all: https://git.openjdk.org/jdk19/pull/89/files - new: https://git.openjdk.org/jdk19/pull/89/files/4d5d4bce..a84c725d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=89&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=89&range=01-02 Stats: 37 lines in 7 files changed: 15 ins; 14 del; 8 mod Patch: https://git.openjdk.org/jdk19/pull/89.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/89/head:pull/89 PR: https://git.openjdk.org/jdk19/pull/89
[jdk19] Integrated: 8289030: [macos] app image signature invalid when creating DMG or PKG
On Wed, 29 Jun 2022 03:03:15 GMT, Alexander Matveev wrote: > Fixed 3 issues which made signature invalid: > - We should not remove .jpackage.xml from signed app image when creating DMG > or PKG otherwise it invalidates signature. > - .package should be created when app image is generated, so this file can be > signed. > - Copying predefine app image for DMG and PKG should not follow symbolic > links, otherwise several files from runtime (COPYRIGHT and LICENSE) will be > copied instead of symbolic links being created, since it invalidates > signature as well. > > Added additional test to validate signature when DMG or PKG is generated from > predefined app image. This pull request has now been integrated. Changeset: 64286074 Author:Alexander Matveev URL: https://git.openjdk.org/jdk19/commit/64286074ba763d4a1e8879d8af69eee34d32cfa6 Stats: 221 lines in 14 files changed: 194 ins; 6 del; 21 mod 8289030: [macos] app image signature invalid when creating DMG or PKG Reviewed-by: asemenyuk - PR: https://git.openjdk.org/jdk19/pull/89
Re: [jdk19] RFR: 8289030: [macos] app image signature invalid when creating DMG or PKG [v3]
On Thu, 7 Jul 2022 19:52:57 GMT, Alexey Semenyuk wrote:
>> We need to add `.package` file during app image creation, since we need to
>> sign it. With your proposed change we will add `.package` file to already
>> signed app image.
>
> Oh, right.
> Anyways let's keep `.package`-related stuff away from
> AbstractAppImageBuilder.java, and AppImageBundler.java.
>
> I'd move `.package`-related logic from AbstractAppImageBuilder to
> MacAppImageBuilder and change
>
> public MacAppBundler() {
> setAppImageSupplier(MacAppImageBuilder::new);
> setParamsValidator(MacAppBundler::doValidate);
> }
>
> to something like this
>
> public MacAppBundler() {
>public MacAppBundler() {
> setAppImageSupplier(imageOutDir -> {
> return new MacAppImageBuilder(imageOutDir, isDependentTask());
> });
> setParamsValidator(MacAppBundler::doValidate);
> }
>
>
> Need to add `AppImageBundler.sDependentTask()` method and change signature if
> MacAppImageBuilder ctor from `MacAppImageBuilder(Path imageOutDir)` to
> `MacAppImageBuilder(Path imageOutDir, boolean withPackageFile)`
Fixed.
-
PR: https://git.openjdk.org/jdk19/pull/89
Re: RFR: 8283707: Support version format on Windows [v2]
On Sat, 16 Jul 2022 22:08:12 GMT, Alexey Semenyuk wrote: >> 8283707: Support version format on Windows > > Alexey Semenyuk has updated the pull request incrementally with one > additional commit since the last revision: > > Comments fixed and better naming in the code. Marked as reviewed by almatvee (Reviewer). - PR: https://git.openjdk.org/jdk/pull/9507
Re: RFR: 8290398: jpackage exe instellers are not installed in jtreg tests
On Sat, 16 Jul 2022 21:22:46 GMT, Alexey Semenyuk wrote: > 8290398: jpackage exe instellers are not installed in jtreg tests Marked as reviewed by almatvee (Reviewer). - PR: https://git.openjdk.org/jdk/pull/9530
Re: RFR: 8290400: Must run exe installers in jpackage jtreg tests without UI
On Sat, 16 Jul 2022 21:32:07 GMT, Alexey Semenyuk wrote: > 8290400: Must run exe installers in jpackage jtreg tests without UI Marked as reviewed by almatvee (Reviewer). - PR: https://git.openjdk.org/jdk/pull/9531
Re: RFR: 8290402: jpackage exe uninstallers don't return correct exit code in case of failure
On Sat, 16 Jul 2022 21:47:43 GMT, Alexey Semenyuk wrote: > 8290402: jpackage exe uninstallers don't return correct exit code in case of > failure src/jdk.jpackage/windows/native/msiwrapper/MsiWrapper.cpp line 53: > 51: > 52: // Uninstall product. > 53: msi::SuppressUI suppressUI; Do you know why this needed and what it do? - PR: https://git.openjdk.org/jdk/pull/9532
Re: RFR: 8290402: jpackage exe uninstallers don't return correct exit code in case of failure
On Sat, 16 Jul 2022 21:47:43 GMT, Alexey Semenyuk wrote: > 8290402: jpackage exe uninstallers don't return correct exit code in case of > failure Marked as reviewed by almatvee (Reviewer). - PR: https://git.openjdk.org/jdk/pull/9532
Re: RFR: 8290557: tools/jpackage/share/AddLauncherTest.java#id1 failed with "ERROR: Failed: Check icon file"
On Fri, 22 Jul 2022 20:21:57 GMT, Alexey Semenyuk wrote: > 8290557: tools/jpackage/share/AddLauncherTest.java#id1 failed with "ERROR: > Failed: Check icon file" Marked as reviewed by almatvee (Reviewer). - PR: https://git.openjdk.org/jdk/pull/9618
Re: RFR: 8291978: jpackage: allow to override primary l10n files on Windows
On Fri, 5 Aug 2022 16:14:35 GMT, Alex Kasko wrote: > This change is a follow-up to [this > comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14512038&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14512038). > > Override implementation is based on [this > comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14510886&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14510886). > > As suggested in [this > comment](https://github.com/openjdk/jdk/pull/9753#pullrequestreview-1062560789) > only English translation is provided for new `resource.wxl-file` label. > > `getTempdirectory` utility was moved from `BasicTest` to `WindowsHelper` to > be able to provide `--temp` and inspect the contents of `config` dir in > verifier. It is not clear if `WindowsHelper` is an appropriate place for this > utility (`BasicTest` is not Windows-specific), I've assumed that `--temp` > flag itself is only used on Windows. > > Testing: > > - [x] enhanced `WinL10nTest` adding checks for `-loc` arguments to > `light.exe` and additional `@Parameter` run that overrides one of the primary > `.wxl` files > - [x] ran jtreg:jdk/tools/jpackage/windows and a `BasicTest` in unpack mode Marked as reviewed by almatvee (Reviewer). - PR: https://git.openjdk.org/jdk/pull/9780
Re: RFR: 8291978: jpackage: allow to override primary l10n files on Windows
On Fri, 5 Aug 2022 16:14:35 GMT, Alex Kasko wrote: > This change is a follow-up to [this > comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14512038&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14512038). > > Override implementation is based on [this > comment](https://bugs.openjdk.org/browse/JDK-8290519?focusedCommentId=14510886&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14510886). > > As suggested in [this > comment](https://github.com/openjdk/jdk/pull/9753#pullrequestreview-1062560789) > only English translation is provided for new `resource.wxl-file` label. > > `getTempdirectory` utility was moved from `BasicTest` to `WindowsHelper` to > be able to provide `--temp` and inspect the contents of `config` dir in > verifier. It is not clear if `WindowsHelper` is an appropriate place for this > utility (`BasicTest` is not Windows-specific), I've assumed that `--temp` > flag itself is only used on Windows. > > Testing: > > - [x] enhanced `WinL10nTest` adding checks for `-loc` arguments to > `light.exe` and additional `@Parameter` run that overrides one of the primary > `.wxl` files > - [x] ran jtreg:jdk/tools/jpackage/windows and a `BasicTest` in unpack mode src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources.properties line 37: > 35: resource.post-app-image-script=script to run after application image is > populated > 36: resource.post-msi-script=script to run after msi file for exe installer > is created > 37: resource.wxl-file=WiX localization file This needs to be added to all WinResources*.properties files. - PR: https://git.openjdk.org/jdk/pull/9780
Re: RFR: 8291924: jpackage: l10n for Windows context menu label [v3]
On Mon, 8 Aug 2022 19:52:41 GMT, Alex Kasko wrote: >> This change adds `ContextMenuCommandLabel` l10n property for file >> association context menu label. It is a follow-up to [this PR >> comment](https://github.com/openjdk/jdk/pull/9224#issuecomment-1169286082). >> >> Note, non-EN l10n values were filled using auto-translator and may need to >> be corrected. >> >> To check the contents of the label, registry query is added to >> `PackageTest::addHelloAppFileAssociationsVerifier`. >> >> Testing: >> >> - [x] ran `FileAssociationsTest` with `install` enabled > > Alex Kasko has updated the pull request incrementally with one additional > commit since the last revision: > > add english entries to l10n files Marked as reviewed by almatvee (Reviewer). - PR: https://git.openjdk.org/jdk/pull/9753
Re: RFR: 8292316: Tests should not rely on specific JAR file names (jpackage)
On Fri, 19 Aug 2022 15:41:47 GMT, Alexey Semenyuk wrote:
> Get rid of dependencies on specific jtreg's jars from jpackage junit tests.
>
> The troublesome statement was `* @library ${jtreg.home}/lib/junit.jar
> ${jtreg.home}/lib/hamcrest.jar` in "junit.java". The fix removes "junit.java"
> and the corresponding "run_junit.sh" file and adds jtreg test declarations to
> each junit test.
Marked as reviewed by almatvee (Reviewer).
-
PR: https://git.openjdk.org/jdk/pull/9944
Re: jpackage OS/X --app-image signing
Hi Michael, Did you generate application image with same JDK version (19+36-2238)? With latest JDK version .jpackage.xml file should be present. We do not support signing of application images generate by another versions of JDK. It should be same JDK. Thanks, Alexander > On Sep 5, 2022, at 4:15 PM, Michael Hall wrote: > > The 19 release candidate appears to have new issues on this? > > java --version > openjdk 19 2022-09-20 > OpenJDK Runtime Environment (build 19+36-2238) > OpenJDK 64-Bit Server VM (build 19+36-2238, mixed mode, sharing) > > which jpackage > jpackage: aliased to > /Library/Java/JavaVirtualMachines/jdk-19.jdk/Contents/Home/bin/jpackage > > jpackage --version > 19 > > jpackage --type app-image --app-image > ~/Blackjack_Blastoff/bjb/bjb_jpkg/BlackJack\ Blastoff_Unsigned.app --mac-sign > --mac-signing-key-user-name "Developer ID Application: Michael Hall > (5X6BXQB3Q7)" > Error: app-image dir (/Users/mjh/Blackjack_Blastoff/bjb/bjb_jpkg/BlackJack > Blastoff_Unsigned.app) generated by another jpackage version or malformed > .jpackage.xml > > ls -l > total 4224 > drwxr-xr-x 3 mjh staff 96 Sep 5 17:50 BlackJack Blastoff_Unsigned.app > … > > I don’t think any information is included in the Info.plist or anywhere else > that indicates which jpackage version was used to build it. (Maybe an idea?) > But I did recreate with the newly installed 19 release candidate. > I’m not sure what the .jpackage.xml is about? > > ls -l .jpackage.xml > ls: .jpackage.xml: No such file or directory
Re: [External] : Re: jpackage OS/X --app-image signing
Hi Michael, I file following issue for this: https://bugs.openjdk.org/browse/JDK-8293462 Yes, you right it is related to JDK-8289030. I put suggested workaround to https://bugs.openjdk.org/browse/JDK-8293462 in comment section. There are two possible workarounds: 1) Generate signed application image initially, then post process it and sign again. 2) Generate unsigned application image and change value of from false to true in "APPNAME.app/Contents/app/.jpackage.xml" and then do post processing and sign it again. There is a bug in "jpackage --type app-image --app-image APPNAME.app --mac-sign” command which signs app image correctly, but never changes value in “.jpackage.xml” to mark image as signed. Thus we will treat such images as unsigned even if they signed and as result we adding “.package” file when generating DMG or PKG from such images. Thanks, Alexander On Sep 7, 2022, at 6:28 AM, Michael Hall mailto:mik3h...@gmail.com>> wrote: On Sep 6, 2022, at 8:00 PM, Michael Hall mailto:mik3h...@gmail.com>> wrote: On Sep 6, 2022, at 4:52 PM, Michael Hall mailto:mik3h...@gmail.com>> wrote: On Sep 6, 2022, at 4:48 PM, Alexander Matveev mailto:alexander.matv...@oracle.com>> wrote: Hi Michael, Did you generate application image with same JDK version (19+36-2238)? With latest JDK version .jpackage.xml file should be present. We do not support signing of application images generate by another versions of JDK. It should be same JDK. Thanks, Alexander Found this explains some of it. Re: [jdk19] RFR: 8289030: [macos] app image signature invalid when creating DMG or PKG [v3] Added this after my build script jpackage invocation to verify .jpackage.xml and version are correct cat "BlackJack Blastoff_Unsigned.app/Contents/app/.jpackage.xml" | grep "jpackage-state version=“ Showing
RFR: 8293462: [macos] app image signature invalid when creating DMG or PKG from post processed signed image
Problem is that [JDK-8286850](https://bugs.openjdk.org/browse/JDK-8286850) never set correct value in .jpackage.xml to mark image as signed. [JDK-8289030](https://bugs.openjdk.org/browse/JDK-8289030) reads this value to check if we can add per-user and system wide configuration to packaged app. Fixed by setting correct value in .jpackage.xml when we signing predefine application image. Added tests to cover this case and added check for values inside .jpackage.xml to validate signed and Mac App Store values. - Commit messages: - 8293462: [macos] app image signature invalid when creating DMG or PKG from post processed signed image Changes: https://git.openjdk.org/jdk/pull/10316/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10316&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293462 Stats: 367 lines in 12 files changed: 303 ins; 15 del; 49 mod Patch: https://git.openjdk.org/jdk/pull/10316.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10316/head:pull/10316 PR: https://git.openjdk.org/jdk/pull/10316
Re: RFR: 8293595: tstrings::any() is missing an overload
On Fri, 9 Sep 2022 13:38:14 GMT, Julian Waters wrote: > tstrings::any() has an overload for std::wstring (if required) but is missing > the corresponding operator overload for std::string, leaving only the > templated one as a fallback, which will expand into a std::wostringstream << > std::string operation. This isn't particularly safe on Windows, considering > that JDK-8292008 and JDK-8247283 have been recently merged, and can > sporadically cause build failures. This change simply adds the missing > overload with the appropriate format handling that jpackage expects from > std::string. Also contains minor name changes to fit the rest of the > parameter names in the other overloads. Marked as reviewed by almatvee (Reviewer). - PR: https://git.openjdk.org/jdk/pull/10231
Re: RFR: 8293462: [macos] app image signature invalid when creating DMG or PKG from post processed signed image [v2]
> Problem is that [JDK-8286850](https://bugs.openjdk.org/browse/JDK-8286850) > never set correct value in .jpackage.xml to mark image as signed. > [JDK-8289030](https://bugs.openjdk.org/browse/JDK-8289030) reads this value > to check if we can add per-user and system wide configuration to packaged > app. Fixed by setting correct value in .jpackage.xml when we signing > predefine application image. > > Added tests to cover this case and added check for values inside > .jpackage.xml to validate signed and Mac App Store values. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8293462: [macos] app image signature invalid when creating DMG or PKG from post processed signed image [v2] - Changes: - all: https://git.openjdk.org/jdk/pull/10316/files - new: https://git.openjdk.org/jdk/pull/10316/files/22ead550..19d4981d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10316&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10316&range=00-01 Stats: 105 lines in 4 files changed: 73 ins; 15 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/10316.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10316/head:pull/10316 PR: https://git.openjdk.org/jdk/pull/10316
Re: RFR: 8293462: [macos] app image signature invalid when creating DMG or PKG from post processed signed image [v2]
On Mon, 19 Sep 2022 18:51:30 GMT, Alexey Semenyuk wrote: >> Alexander Matveev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8293462: [macos] app image signature invalid when creating DMG or PKG from >> post processed signed image [v2] > > src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageFile.java line > 67: > >> 65: private final String mainClass; >> 66: private final List addLauncherInfos; >> 67: private final boolean signed; > > This change defeats the idea of keeping `AppImageFile` immutable. I'd rather > add `AppImageFile.copyAsSigned()` method that will return the same > `AppImageFile` instance if `signed` is `true`, or a copy with `signed` set to > `true` otherwise. > > I'd add `public AppImageFile.save(Path appImageDir)` member function to > serialize `AppImageFile` instance and keep the signature of existing static > `AppImageFile.save` unchanged. I'd make them call static `private > AppImageFile.save(Path appImageDir, Map params, AppImageFile > appImage)` that you have right now in the review. `AppImageFile.save(Path > appImageDir, Map params, AppImageFile appImage)` is > implementation details and should not be a part of class public interface. 8293462: [macos] app image signature invalid when creating DMG or PKG from post processed signed image [v2] - Fixed as suggested. - Moved getAttribute() under LauncherInfo class, since it is used only by this class. - Added unit test for AppImageFile.copyAsSigned(). - PR: https://git.openjdk.org/jdk/pull/10316
Re: RFR: 8293462: [macos] app image signature invalid when creating DMG or PKG from post processed signed image
Hi Michael, On Sep 16, 2022, at 6:19 PM, Michael Hall mailto:mik3h...@gmail.com>> wrote: On Sep 16, 2022, at 6:02 PM, Alexander Matveev mailto:almat...@openjdk.org>> wrote: Problem is that [JDK-8286850](https://bugs.openjdk.org/browse/JDK-8286850) never set correct value in .jpackage.xml to mark image as signed. [JDK-8289030](https://bugs.openjdk.org/browse/JDK-8289030) reads this value to check if we can add per-user and system wide configuration to packaged app. Fixed by setting correct value in .jpackage.xml when we signing predefine application image. Alexander, I think I figured out how to include PR’s in my build and this appears good. codesign -v --verbose=4 "/Volumes/BlackJack Blastoff_Unsigned/BlackJack Blastoff_Unsigned.app" /Volumes/BlackJack Blastoff_Unsigned/BlackJack Blastoff_Unsigned.app: valid on disk /Volumes/BlackJack Blastoff_Unsigned/BlackJack Blastoff_Unsigned.app: satisfies its Designated Requirement This was new… Warning: Support for per-user configuration of the installed application will not be supported due to missing "BlackJack Blastoff_Unsigned.app/Contents/app/.package" in predefined signed application image. I’m not quite sure what it’s saying but it doesn’t seem to impact what I’m doing. This warning means that support for per-user configuration of the installed application will be disabled. We added support for per-user configuration with https://bugs.openjdk.org/browse/JDK-8250950 (Allow per-user and system wide configuration of a jpackaged app). Thanks, Alexander Thanks, Mike FWIW, I ran into [macos] cmstypes.c fails compilation with Xcode13.3 https://bugs.openjdk.org/browse/JDK-8283221 Adding this which I noticed in the source… cmsUNUSED_PARAMETER(SizeOfTag);// mjh To the two erroring methods… ~/Documents/GitHub/jdk/build/macosx-x86_64-server-release/build.log:179: /Users/mjh/Documents/GitHub/jdk/src/java.desktop/share/native/liblcms/cmstypes.c:3441:132: error: parameter 'SizeOfTag' set but not used [-Werror,-Wunused-but-set-parameter] ~/Documents/GitHub/jdk/build/macosx-x86_64-server-release/build.log:182: /Users/mjh/Documents/GitHub/jdk/src/java.desktop/share/native/liblcms/cmstypes.c:5137:125: error: parameter 'SizeOfTag' set but not used [-Werror,-Wunused-but-set-parameter] Seemed a fix. I could build.
Re: RFR: 8293462: [macos] app image signature invalid when creating DMG or PKG from post processed signed image [v2]
On Fri, 23 Sep 2022 20:40:29 GMT, Alexey Semenyuk wrote:
>> Alexander Matveev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8293462: [macos] app image signature invalid when creating DMG or PKG from
>> post processed signed image [v2]
>
> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppImageBuilder.java
> line 286:
>
>> 284: if (appImageFile != null) {
>> 285: appImageFile.save(predefinedAppImage);
>> 286: }
>
> Wouldn't it make sense to rethrow caught exception after the file is restored?
Fixed.
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageFile.java line
> 64:
>
>> 62:
>> 63: // These values will be loaded from AppImage xml file.
>> 64: private final Path appImageDir;
>
> What this field is for? This property doesn't belong to the class.
It was used to show path to .jpackage.xml file in case of error from
copyAsSigned(), but it is actually not needed, since copyAsSigned() should not
produce invalid app image file.
-
PR: https://git.openjdk.org/jdk/pull/10316
Re: RFR: 8293462: [macos] app image signature invalid when creating DMG or PKG from post processed signed image [v3]
> Problem is that [JDK-8286850](https://bugs.openjdk.org/browse/JDK-8286850) > never set correct value in .jpackage.xml to mark image as signed. > [JDK-8289030](https://bugs.openjdk.org/browse/JDK-8289030) reads this value > to check if we can add per-user and system wide configuration to packaged > app. Fixed by setting correct value in .jpackage.xml when we signing > predefine application image. > > Added tests to cover this case and added check for values inside > .jpackage.xml to validate signed and Mac App Store values. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8293462: [macos] app image signature invalid when creating DMG or PKG from post processed signed image [v3] - Changes: - all: https://git.openjdk.org/jdk/pull/10316/files - new: https://git.openjdk.org/jdk/pull/10316/files/19d4981d..5598345c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10316&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10316&range=01-02 Stats: 20 lines in 2 files changed: 5 ins; 14 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10316.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10316/head:pull/10316 PR: https://git.openjdk.org/jdk/pull/10316
Integrated: 8293462: [macos] app image signature invalid when creating DMG or PKG from post processed signed image
On Fri, 16 Sep 2022 22:55:52 GMT, Alexander Matveev wrote: > Problem is that [JDK-8286850](https://bugs.openjdk.org/browse/JDK-8286850) > never set correct value in .jpackage.xml to mark image as signed. > [JDK-8289030](https://bugs.openjdk.org/browse/JDK-8289030) reads this value > to check if we can add per-user and system wide configuration to packaged > app. Fixed by setting correct value in .jpackage.xml when we signing > predefine application image. > > Added tests to cover this case and added check for values inside > .jpackage.xml to validate signed and Mac App Store values. This pull request has now been integrated. Changeset: 1e222bcc Author:Alexander Matveev URL: https://git.openjdk.org/jdk/commit/1e222bccd3807c1be0d1d824e0ff9745751d8375 Stats: 423 lines in 12 files changed: 356 ins; 19 del; 48 mod 8293462: [macos] app image signature invalid when creating DMG or PKG from post processed signed image Reviewed-by: asemenyuk - PR: https://git.openjdk.org/jdk/pull/10316
Re: RFR: 8311631: When multiple users run tools/jpackage/share/LicenseTest.java, Permission denied for writing /var/tmp/*.files [v2]
On Thu, 13 Jul 2023 07:27:22 GMT, yaqsun wrote: >> The prerequisite is to install the rpmbuild command, when multiple users >> switch to write /var/tmp/*.files will have the permission forbidden. > > yaqsun has updated the pull request incrementally with one additional commit > since the last revision: > > 8311631: When multiple users run tools/jpackage/share/LicenseTest.java, > Permission denied for writing /var/tmp/*.files Marked as reviewed by almatvee (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/14802#pullrequestreview-1535814977
Re: RFR: JDK-8309032: jpackage does not work for module projects unless --module-path is specified
On Tue, 11 Jul 2023 23:47:30 GMT, airsquared wrote: > [JDK-8309032](https://bugs.openjdk.org/browse/JDK-8309032), > [JDK-8306488](https://bugs.openjdk.org/browse/JDK-8306488) Marked as reviewed by almatvee (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/14840#pullrequestreview-1538311227
Re: RFR: JDK-8309032: jpackage does not work for module projects unless --module-path is specified
On Thu, 20 Jul 2023 02:04:53 GMT, Alexey Semenyuk wrote: >> [JDK-8309032](https://bugs.openjdk.org/browse/JDK-8309032), >> [JDK-8306488](https://bugs.openjdk.org/browse/JDK-8306488) > > @sashamatveev would you like to review the change before I sponsor it? @alexeysemenyukoracle Looks good. - PR Comment: https://git.openjdk.org/jdk/pull/14840#issuecomment-1643003305
Re: RFR: 8312488: tools/jpackage/share/AppLauncherEnvTest.java fails with dynamically linked libstdc++
On Fri, 21 Jul 2023 10:55:13 GMT, Vladimir Petko wrote: > Use the same approach as Logger::defaultLogger() to ensure that the appender > is not destroyed before shared object destructor function is executed. > > The alternative is to delete dcon() function, but we might run into a > similiar tear-down issue later (e.g. logging from some object's destructor). > > > == > Test summary > == >TEST TOTAL PASS FAIL ERROR > >jtreg:test/jdk/tools215 215 0 0 > > == > TEST SUCCESS src/jdk.jpackage/share/native/common/app.cpp line 2: > 1: /* > 2: * Copyright (c) 2020, 2023 Oracle and/or its affiliates. All rights > reserved. Missing "," after 2023. Should be: "Copyright (c) 2020, 2023, Oracle and/or its affiliates.". - PR Review Comment: https://git.openjdk.org/jdk/pull/14971#discussion_r1271102509
Re: RFR: 8312488: tools/jpackage/share/AppLauncherEnvTest.java fails with dynamically linked libstdc++ [v2]
On Sat, 22 Jul 2023 21:41:06 GMT, Vladimir Petko wrote: >> Use the same approach as Logger::defaultLogger() to ensure that the >> appender is not destroyed before shared object destructor function is >> executed. >> >> The alternative is to delete dcon() function, but we might run into a >> similiar tear-down issue later (e.g. logging from some object's destructor). >> >> >> == >> Test summary >> == >>TEST TOTAL PASS FAIL ERROR >> >>jtreg:test/jdk/tools215 215 0 0 >> >> == >> TEST SUCCESS > > Vladimir Petko has updated the pull request incrementally with one additional > commit since the last revision: > > copyright typo Marked as reviewed by almatvee (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/14971#pullrequestreview-1543908185
