[External] : Re: RFR: 8350594: Misleading warning about install dir for DMG packaging

[Michael Hall]

> On Mar 4, 2025, at 10:06 AM, Michael Hall <mik3hall at gmail.com> wrote:
> 
>>> 
>> Good point about `CFBundleGetInfoString`. Maybe jpackage should set this field with the value of `--description` option. Another finding!
>> 
>> As for editing "Info.plist" from the runtime source, if the directory referenced from `--runtime-image` option is a valid bundle, i.e. has "Contents/MacOS/libjli.dylib", "Contents/Info.plist" files, and "Contents/_CodeSignature" elements, and there are no other options, like `--app-version`, jpackage should use the supplied directory as-is without editing the existing "Info.plist" file. Otherwise, jpackage should create "Info.plist" and make sure the values are consistent, of course.
> 
> I posted an example, there are a few other places in Info.plist that would also need changing to the correct version if you don’t already have a valid Info.plist for the JRE. The page of mine that you linked I think mentioned them all.
> 
> __CodeSignature I didn’t include in what I did. It seemed like you might not be able to copy this but would need to do your own signing to generate it for a different JRE? My guess was that it is only really needed for an application distribution including that JRE. I know jpackage does some of its own signing. If this recreates the JRE __CodeSignature, this probably wouldn’t be a concern. 
> 
> It is possible if you are provided with a JRE where all this is correct then copying as-is would be fine. However, if you are copying a JRE that already has a JavaVirtualMachines file for that version I’m not sure what would happen. That should be checked? If you are providing a later release the new one should be used. If you are providing an earlier release the one you are adding will be ignored. Warnings at least? /usr/libexec/java_home -v <target.version> could maybe be useful here. I think though you would need to determine the version of what you are copying in.
> 
> Assuming the JRE you are adding to JavaVirtualMachines is a unique or current one for that java version then I think some fairly simple test like java —version or something again with /usr/libexec/java_home could verify that everything is alright. 
> 

I didn’t really think that through. I just realized that if you have a dmg with a JRE that the user will install onto their own machine all the version related will depend on what they have in their own JavaVirtualMachines. You can’t really do any install checking on a drag and drop. So I guess that would be at their own risk. You could still do some verification on adding the JRE to a dmg to ensure its validity for the Mac specific files.