RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles

[Alexey Semenyuk]

On Tue, 20 May 2025 00:47:09 GMT, Alexander Matveev <almatvee at 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.

The description is missing some important changes:
 - jpackage will attempt to get a package version from the JDK's release file if the `--version` option is not specified.
 - The bundle's top directory name will have the ".jdk" suffix.

I like the idea of reading the package's version from the JDK's release file when bundling a runtime package, but it is out of the scope of the "jpackage produces invalid Java runtime DMG bundles" fix. It should be a separate fix.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25314#issuecomment-2895251471