[External] : Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe

[Michael Hall]

> On May 17, 2022, at 12:15 AM, Alexander Matveev <alexander.matveev at oracle.com> wrote:
> 
> Hi Michael,
> 
> I filed following enhancement for signing user provided app image and yes it will be two step process. Invoke jpackage to generate image, then user can modified it and then invoke jpackage again to sign it.
> https://bugs.openjdk.java.net/browse/JDK-8286850
> 
> For JDK-8286122, I will integrate proposed fix as is. Error will be thrown if user tries to include native commands for Mac App Store image.
> 
> Still not sure if we will provide solution for including native commands with Mac App Store. Including special versions of native commands with jpackage will work only if runtime is generated by jpackage. It will not solve issue with user provided runtime. Also, it is not clear if app updates will require same unique ID based on UUID across app versions.

This enhancement doesn’t directly concern this issue. Although given this enhancement it would be possible to provide a temporary ‘hack’ fix without building it into jpackage. Where the executables are changed to make them unique in the post-processing step. If it is not your intention to address this issue given this enhancement you would probably have to check the provided application bundle to be sure it doesn’t have the colliding Info.plist native commands. What Apple DTS provided may of had commands for this? I don’t remember. Or you would have to just fail any passed application bundles with native java commands.

From https://bugs.openjdk.java.net/browse/JDK-8286850 <https://bugs.openjdk.java.net/browse/JDK-8286850>

> Generating DMG or PKG from —app-image with signing enabled will not sign app image as it currently do.

I am not sure you would want to change this. If the developer doesn’t want to do any post-processing of the application bundle then they should be able to use the current invocations unchanged to do this?
I would think if you want post-processing you would generate unsigned applications, post-process, use the enhancement to sign. 


> 
> Also, many functionality provided by native JDK commands can be used via ToolProvider. For example if you include jdk.jpackage module with your app, you should able to use jpackage functionality from your app via ToolProvider without actual jpackage native command.
> 
> Thanks,
> Alexander

Which might be another way this could be useful. If any 3rd parties want to generate their own application bundles they could still use jpackage as the definitive way to sign those.

Thanks 
Mike
>