> On Mar 4, 2025, at 10:20 AM, Alexey Semenyuk <alexey.semen...@oracle.com> > wrote: > > > > On 3/4/2025 11:06 AM, Michael Hall 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. > Right. If you package unpacked official OpenJDK tar.gz jpackage should take > it as is. > >> However, if you are copying a JRE that already has a JavaVirtualMachines >> file for that version I’m not sure what would happen. > The same as in the above case, I guess. jpackage should take it as is. > >> That should be checked? If you are providing a later release the new one >> should be used. > Sorry, I don't follow. What release do you mean? > >> 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. > jpackage doesn't control how you use bundles it produces. You can use the > same input runtime image and create two separate bundles with different > names, but with the same versions and install them both. > > - Alexey
Sorry again that I was thinking something could be done for the actual install on the users machine which it can’t. If you are using this for official release installs yes, it should be no problem copying it as-is. More or less what I do manually and it has worked just fine. If it is a jpackage option that others might use, which as you indicate, it is. My suggestion is that jpackage can do some checking of its validity. I was trying a number of different things, some very different and all were accepted, none were valid JavaVirtualMachine system runtimes. As a further enhancement I think it would be possible if the MacOS needed files are not there for jpackage to supply them to make it a valid JavaVirtualMachines system jre. My Info.plist example showed a way you could make all needed version/description changes using /usr/libexec/PlistBuddy. I believe jpackage currently relies on issuing just such native commands. Maybe some future use of that for jpackage could also turn up. This is why I thought about writing a plist editor for jpackage application build use. Signing if needed I’m sure you could manage, you probably already address the issues. As mentioned I manually put together a JavaVirtualMachines runtime from a built jdk that seemed to work fine command line and when used as the user specified runtime for a fairly complex application. For some reason it didn’t work to automatically jlink from. This led to other issues when I tried to address —add-modules needed for JavaFX. So there might be some non-trivial complications that I didn’t resolve. Thanks yet again for the follow-up.
