On Wed, 16 Jul 2025 02:01:57 GMT, Alexander Matveev <almat...@openjdk.org> wrote:
>> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge >> conflict was resolved. Old PR will be closed. >> >> All comments are addressed from old PR. Merge conflict was significant, so >> it is like new fix. >> >> 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. >> >> Additional changes: >> - The bundle's top directory name will have the ".jdk" suffix. > > Alexander Matveev has updated the pull request incrementally with one > additional commit since the last revision: > > 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v4] src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/Package.java line 158: > 156: * package > 157: */ > 158: Optional<Path> predefinedAppOrRuntimeImage(); Let's keep the name unchanged. It fits both application and runtime packaging. If it were `predefinedApplicationImage()`, I would suggest changing it to `predefinedAppImage()` anyway :). Let's just update the javadoc: /** * Gets the path to a directory with the predefined app image of this package if * available or an empty {@link Optional} instance otherwise. * <p> * If {@link #isRuntimeInstaller()} returns {@code true}, the method returns the * path to a directory with the predefined runtime. The layout of this directory * should be of {@link RuntimeLayout} type. * <p> * If {@link #isRuntimeInstaller()} returns {@code false}, the method returns * the path to a directory with the predefined application image. The layout of * this directory should be of {@link ApplicationLayout} type. * * @return the path to a directory with the application app image of this * package */ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2210608592
