On Tue, 20 May 2025 00:47:09 GMT, Alexander Matveev <almat...@openjdk.org> wrote:
> Fixed jpackage to produce valid Java runtimes based on description below: > > Definitions: > > - JDK bundle defined as bundle which contains "Contents/Home", > "Contents/MacOS/libjli.dylib" and "Contents/Info.plist". > - Signed JDK bundle contains all files as JDK bundle + > "Contents/_CodeSignature". > - JDK image defined as content of "Contents/Home". > - Signed JDK image does not exist, since it cannot be signed as bundle. > > jpackage output based on input: > > 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not > provided: > - jpackage will copy all files as is from provided path and run ad-hoc > codesign. > > 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided: > - jpackage will copy all files as is from provided path and run codesign with > appropriate certificate based on same logic as we do for application image. > > 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not > provided: > - jpackage will copy all files as is from provided path including > "Contents/_CodeSignature" to preserve signing. > > 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided: > - jpackage will copy all files as is from provided path including > "Contents/_CodeSignature" and will re-sign bundle with appropriate > certificate. > > 5. "--runtime-image" points to JDK image and --mac-sign is not provided: > - jpackage will check for libjli.dylib presence in "lib" folder. > - Create JDK bundle by putting all files from provided path to > "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and > create default "Contents/Info.plist" similar to what we do for runtime in > application image. > - Ad-hoc signing will done. > > 6. "--runtime-image" points to JDK image and --mac-sign is provided: > - 2 first steps from 5 and certificate signing will be done. src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java line 199: > 197: } > 198: return version; > 199: }, I guess, this is a workaround for the case when the version comes from JDK's release file. This is the wrong place for this workaround. It should be a part of the code reading version from JDK's release file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2098462753
