Bug ID: JDK-8356218 [macos] Document --app-content

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 26
26 b13Fixed

On macos, misuse of the --app-content cli option may fail jpackage to sign an app bundle or later notarization failure.

On macos, the value of the "--app-content" cli option should point to a directory with the "Resources" subdirectory or any other directory that can be created in the app's "Contents" directory. See [1] for more details about the macos app bundle structure.

This restriction is not currently documented anywhere. Adding it to the help, man page, and user's guide would be helpful.

It would also be helpful for jpackage to issue warnings for every item pulled in the app bundle with "--app-content" options not satisfying this restriction.

jpackage will output a warning if it fails signing, and the "--app-content" option was specified. It was introduced in JDK-8332110, but it is not very helpful as it is not specific. Besides, the warning is displayed only when jpackage fails to sign the app image. If they run jpackage without "--mac-sign" option, the warning will not be displayed, even though the app bundle structure may be invalidated with files pulled in the app image through "--app-content" option.

See https://github.com/openjdk/jdk/pull/21698#issuecomment-2849491184

[1] https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html#//apple_ref/doc/uid/10000123i-CH101-SW19

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk25u/pull/357 Date: 2025-11-04 18:24:57 +0000
04-11-2025
Changeset: 7b9969dc Branch: master Author: Alexander Matveev <almatvee@openjdk.org> Date: 2025-08-22 22:24:39 +0000 URL: https://git.openjdk.org/jdk/commit/7b9969dc8f20989497ff617abb45543d182b684d
22-08-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/26848 Date: 2025-08-19 20:07:10 +0000
19-08-2025
> If they run jpackage without "--mac-sign" option, the warning will not be displayed, even though the app bundle structure may be invalidated with files pulled in the app image through "--app-content" option. Not true. I tried following command line and it failed with warning: jpackage --type dmg -i input -n Test --main-class components.DynamicTreeDemo --main-jar DynamicTreeDemo.jar --app-content content/Resources/ReadMe1.txt "codesign" failed and additional application content was supplied via the "--app-content" parameter. Probably the additional content broke the integrity of the application bundle and caused the failure. Ensure content supplied via the "--app-content" parameter does not break the integrity of the application bundle, or add it in the post-processing step. Error: "codesign" failed with following output: /var/folders/dr/65dj5x3j0296mqtsn9z27xc80000gn/T/jdk.jpackage11350735134267763257/image/Test.app: replacing existing signature /var/folders/dr/65dj5x3j0296mqtsn9z27xc80000gn/T/jdk.jpackage11350735134267763257/image/Test.app: code object is not signed at all In subcomponent: /private/var/folders/dr/65dj5x3j0296mqtsn9z27xc80000gn/T/jdk.jpackage11350735134267763257/image/Test.app/Contents/ReadMe1.txt jdk.jpackage.internal.Codesign$CodesignException We will print warning if ad-hoc signing fails. Maybe in reported case ad-hoc signing did not failed.
15-08-2025