RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443 for same reason on older macOS versions

Michael Hall mik3hall at gmail.com
Sat May 3 21:14:45 UTC 2025



> On May 3, 2025, at 3:58 PM, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:
> 
> On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:
> 
>> - It is not clear on which macOS versions codesign fails if application bundle contains additional content.
>> - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content.
>> - This change is for macOS only.
>> - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not.
> 
> So the takeaway from this fruitful discussion is:
> - jpackage doesn't produce helpful verbose signing output. Filed [JDK-8356116](https://bugs.openjdk.org/browse/JDK-8356116)

I was mistaken on this. The codesign parameters appear to be shown once. Then there are many messages indicating just that codesign is being run.
If the same parameters are always used indicating the parameters for each message probably isn’t needed.

> - jpackage doesn't produce a notarizable app image if `--app-content` is used. Filed [JDK-8356117](https://bugs.openjdk.org/browse/JDK-8356117)
> 
> -------------
> 
> PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2848805427

I may of missed this as well. I thought the original poster indicated that changing the signing parameters somehow gave them a fix.
If so, and doing it only once works, all the additional codesign’s that jpackage seems to do might not be necessary?
Although if his fix depended on using —deep that currently shows as deprecated in the man page.

I would think that only executable content would need signing? —app-content I don’t think adds anything for that.
If it doesn’t break signing, and I see there is a SigningOptionsTest that appears to include it, I wouldn’t think it would break notarization either.

But I don’t know. Other than testing some time back I don’t notarize.



More information about the core-libs-dev mailing list