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

[Michael Hall]

> 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?