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 <mik3h...@gmail.com> Date: Friday, October 25, 2024 at 5:52 PM To: Alexander Matveev <almat...@openjdk.org> Cc: core-libs-dev <core-libs-dev@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 <almat...@openjdk.org> wrote: > > On Fri, 25 Oct 2024 21:55:58 GMT, Michael Hall <mik3h...@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?
