[This issue was co-authored with Claude Code. -Joe]
Background
The macOS release workflow (ci-release.yml, Build macOS DMG job) emits signing warnings of the form:
[ERROR] In architecture: i386
[ERROR] org/jline/nativ/Mac/x86/libjlinenative.jnilib: signed Mach-O thin (i386) [libjlinenative]
Surfaced 4× in the 7.0.0-beta3 release run (https://github.com/eXist-db/exist/actions/runs/26822492422) but did not fail signing or notarization. Raised by @duncdrum on PR #6434 (#6434 (comment)).
Why this matters
macOS dropped 32-bit / i386 support in 10.15 (Catalina, 2019). Any i386 binary inside the bundle is dead weight: it cannot be executed on any supported macOS host, but it still:
- Triggers codesign warnings on every release build (noise in the notarization log).
- Bloats the DMG.
- Risks future Apple-tooling friction as Apple continues to deprecate 32-bit handling.
The slice is bundled inside jline's native lib (org/jline/nativ/Mac/x86/libjlinenative.jnilib), inside the jline JAR.
Two cleanup paths
Option A — bump jline if upstream has dropped the i386 slice
If a current jline release ships only arm64 + x86_64 Mach-O slices, the cleanest fix is a dependabot-style version bump. Action items:
- Identify jline current pinned version in
pom.xml (look for jline.version).
- Check jline release notes for "drop i386" / "arm64-only universal binary" notes.
- Upgrade and re-run the macOS DMG build; confirm the
In architecture: i386 lines are gone from the signing step.
Option B — strip i386 ourselves during DMG-prep
If jline still ships i386, use lipo -remove i386 <jnilib> -output <jnilib> as a build step before the codesign step in exist-distribution. The JAR layout would need to be unpacked/repacked, but this is feasible and self-contained.
Recommendation
Start with (A) since it's lower-effort and lower-risk. Fall back to (B) only if jline upstream is unresponsive or hasn't dropped i386.
Out of scope
- Other native libs in the bundle (lz4-java, jansi, etc.) — none have shown the same i386 warning in recent release runs, but a follow-up sweep of all bundled
.jnilib / .dylib files would be prudent and could be folded into whichever option lands.
Related
[This issue was co-authored with Claude Code. -Joe]
Background
The macOS release workflow (
ci-release.yml,Build macOS DMGjob) emits signing warnings of the form:Surfaced 4× in the 7.0.0-beta3 release run (https://github.com/eXist-db/exist/actions/runs/26822492422) but did not fail signing or notarization. Raised by @duncdrum on PR #6434 (#6434 (comment)).
Why this matters
macOS dropped 32-bit / i386 support in 10.15 (Catalina, 2019). Any i386 binary inside the bundle is dead weight: it cannot be executed on any supported macOS host, but it still:
The slice is bundled inside
jline's native lib (org/jline/nativ/Mac/x86/libjlinenative.jnilib), inside thejlineJAR.Two cleanup paths
Option A — bump jline if upstream has dropped the i386 slice
If a current jline release ships only
arm64+x86_64Mach-O slices, the cleanest fix is a dependabot-style version bump. Action items:pom.xml(look forjline.version).In architecture: i386lines are gone from the signing step.Option B — strip i386 ourselves during DMG-prep
If jline still ships i386, use
lipo -remove i386 <jnilib> -output <jnilib>as a build step before the codesign step inexist-distribution. The JAR layout would need to be unpacked/repacked, but this is feasible and self-contained.Recommendation
Start with (A) since it's lower-effort and lower-risk. Fall back to (B) only if jline upstream is unresponsive or hasn't dropped i386.
Out of scope
.jnilib/.dylibfiles would be prudent and could be folded into whichever option lands.Related
jvmRequired21 → 21+ (another follow-up from the same review)