RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443 for same reason on older macOS versions

[Alexander Matveev]

Hi Michael,

> They would also, files in the app directory, all be automatically code signed I think wouldn’t they?
Yes, files under app directory will be signed as well.

Thanks,
Alexander

From: Michael Hall <mik3hall at gmail.com>
Date: Friday, October 25, 2024 at 5:52 PM
To: Alexander Matveev <almatvee at openjdk.org>
Cc: core-libs-dev <core-libs-dev at openjdk.org>
Subject: Re: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443 for same reason on older macOS versions


> On Oct 25, 2024, at 7:31 PM, Alexander Matveev <almatvee at openjdk.org> wrote:
>
> On Fri, 25 Oct 2024 21:55:58 GMT, Michael Hall <mik3hall at gmail.com> wrote:
>
>> So these both still return the failing error code?
> Yes, jpackage will return failing error case.
>
>> Are these changes only related to the test or do they apply somehow to normal usage?
> Change is for test only. Test will ignore jpackage error code. jpackage itself will work as before.

Thanks

>
>> I?m not sure what the additional files are. Extra files that go into the app directory? Or where do they go?
> Extra files will go to TestAppName.app/Contents.
>

OK. I’m not sure how applications are accessing files here. Being able to have everything that’s in the input directory end up in the app directory I think would be able to serve the same purpose without needing an additional cli arg that requires special handling. Java apps can locate files there with a java option of something like, -Dapp.path=$APPDIR. Or figure it out from something in java.class.path. They could directly resource load from here if the app directory itself was in class path? I don’t remember if I enhancement requested that or not.

They would also, files in the app directory, all be automatically code signed I think wouldn’t they?



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241028/c2d4e9e8/attachment.htm>