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

[Michael Hall]

>> 
> 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.