> On May 19, 2022, at 5:38 PM, Alexander Matveev <alexander.matv...@oracle.com>
> wrote:
>
> Hi Michael,
Alexander
>
> I think it will be a problem to implement this for native launchers.
Each of the native commands is it’s own app launcher? I didn’t know this. I
don’t think it was ever really indicated in the discussion why the commands
needed the embedded plist. I think Apple DTS guessed it had something to do
with a TCC issue.
> - If we extract native launchers inside installed app bundle it will
> invalidate signature and most likely will require privileged permissions to
> write inside app bundle.
I thought maybe jpackage unsigned and resigned the jdk itself. Maybe not. I was
talking about simply including a jar in input that ends up in the ‘app’
directory and the app then has the jar contents extracted from there. No
additional write permission’s are required.
> - If we extract to some known and accessible location as you suggesting, then
> how our launchers will figure out which runtime to use? All other runtime
> files will be inside app bundle.
Again this possibly my not understanding what additional requirements there are
for the commands to be ‘launchers’. I was thinking if the embedded plist was
still a problem the developer could possibly use commands from a compatible
linux distribution. OS/X and linux are both Unix right? It did occur to me that
extracting native commands out of a jar might lose the executable posix
permission. I’m not sure if jar has any builtin meta information to retain
these permissions or if nio allows you to set executable. I haven’t had to
address this.
> - If user deletes application, then how we will cleanup extracted files? Most
> likely it will require uninstall script in known location which user will
> need to run in order to cleanup extracted files.
I haven’t tried to address this yet myself for my application. I’m not sure a
lot of OS/X application’s do. But it would probably be up to the app to provide
an uninstall of some kind. Some app’s are obviously going to need external data.
>
> Thanks,
> Alexander
>
Again I’m suggesting it as a roughed out workaround suggestion for the
developer. There might be issues they would need to work out and might even be
problems where it won’t work.
I’m not suggesting it as a fix you would try to implement.
Thanks
Mike
