[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 16, 2022, at 7:09 PM, Alexander Matveev <alexander.matveev at oracle.com> wrote:
> 
> Hi Michael,
> 
>> 
>>>> 
>>>> I’m not real familiar with the build process. But would it be possible for the user to build their own jdk that substitutes something else for the colliding identifier that gets embedded?
>>> Yes, it should be possible and in theory such JDK with native commands can be used. However, current fix will not allow such JDK build, since we checking for presence of “bin” folder and not if ID is actually unique. To work around this limitation user can package without native commands first, then add native commands and re-sign application.
>> 
>> Signing is currently an integrated part of the process. I thought about making an enhancement request to have it possible to do it stepped. First build the application, then allow the user to post-process that. Maybe run a tool/script to modify the application level Info.plist file. Then allow a second final step that does the signing. I don’t remember if I actually made that enhancement request. But currently there is no way with jpackage to standalone sign the application is there? I think this is somewhat involved with the application bundle being iterated and for one thing each jar being separately code signed? I think it took a release or two of the command to get this correct. So I doubt Xcode could manage it. Is there a way to do the signing standalone with jpackage that I am not aware of?
>> 
>> If I didn’t do an enhancement request on this I could, if you think jpackage could manage it?
>> 
> 
> There is no a way to do the signing of standalone app image and app image will not get signed if you generating DMG or PKG by providing app image via —app-image and specifing signing. Only PKG will get signed if signing is specified with —app-image.
> 
> Currently jpackage will block following command:
> jpackage --type app-image --app-image Test.app --mac-sign ...
> Error: Option [--app-image] is not valid with type [app-image]
> 
> I think we can allow app-image type with app image input if signing is requested and command from above will just sign app image in place.
> 
> Generating DMG or PKG from —app-image and with signing enabled will not sign app image as it currently do.
> 
> If no objections for proposed enhancement I will go ahead and file one.
> 
> Thanks,
> Alexander

Alexander

I’m not entirely sure I’m following this. I assumed it wasn’t currently possible to do standalone signing against an application bundle but would require an enhancement request. If you are saying you will do that request yourself, that’s fine.
Again, I think this should be possible as a two step process. The first would be to generate the application bundle. Then perform some application bundle post-processing, probably independent of jpackage. Finally allow a jpackage invocation that takes the path to the completed application bundle and performs the signing. 
If this is what you are thinking we are on the same page. 

Thanks
Mike