Skip to content

Add macOS Intel build and fix mac code signing via jpackage - #65

Merged
DonaldChung-HK merged 1 commit into
mainfrom
build-mac-intel-final
Aug 7, 2026
Merged

Add macOS Intel build and fix mac code signing via jpackage#65
DonaldChung-HK merged 1 commit into
mainfrom
build-mac-intel-final

Conversation

@DonaldChung-HK

Copy link
Copy Markdown
Contributor

Summary

  • Add a macos-26-intel matrix entry to package.yml so the release pipeline builds both Apple Silicon (arm64) and Intel (x64) macOS artifacts, alongside the existing Windows/Linux builds.
  • Switch mac packaging from fvarrui/javapackager's mac bundler to the JDK's own jpackage (new package-mac Maven profile, auto-activated on macOS): javapackager's launcher script isn't a Mach-O binary, so rcodesign couldn't sign it ("Invalid magic number").
  • Strip CFBundleExecutable from Contents/runtime/Contents/Info.plist before signing, working around a known jpackage quirk (OpenJDK JDK-8237490) where libjli.dylib otherwise gets signed twice and notarization rejects it.
  • Trim build artifact target list to shrink the artifact bundle.

Test plan

  • [*] Trigger the Package Multiplatform Installers workflow (workflow_dispatch, test mode) and confirm both CertWizard-Mac-ARM64-APP and CertWizard-Mac-x64-APP artifacts build and sign successfully.
  • [*] Manually signed and notarised the the produced .app with rcodesign successfully.
  • [*] Manual testing by macbook owners that it can run and passed notarisation gate.

GitHub only offers Apple Silicon macOS runners for standard builds, so
add a macos-26-intel matrix entry to package.yml to also produce an
x64 build, alongside the existing arm64 one.

Switch the mac packaging profile from fvarrui/javapackager's mac
bundler to the JDK's own jpackage. javapackager's mac launcher
(universalJavaApplicationStub) is a shell script, not a Mach-O binary,
so rcodesign can't sign the resulting bundle ("Invalid magic number").
jpackage produces a real compiled launcher that both codesign and
rcodesign can sign correctly.

jpackage's runtime bundle also trips a known jpackage quirk (OpenJDK
JDK-8237490): Contents/runtime/Contents/Info.plist declares
libjli.dylib as CFBundleExecutable, causing it to be signed twice
(once as a nested bundle's main executable, once generically) which
notarization rejects. Strip CFBundleExecutable from that plist before
signing so libjli.dylib is only signed once.
@DonaldChung-HK
DonaldChung-HK merged commit ce4a24b into main Aug 7, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants