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