Конец 2019 г. У меня было нотариальное заверение c моего работающего приложения Java 8, в феврале 2020 г. Apple ужесточила правила, касающиеся нотариального заверения, и это помешало моему приложению быть нотариально заверенным. Так как мне все равно нужно было перейти на Java 11, я переключился на Java 11, так как понял, что это можно сделать нотариально, и произвел необходимые изменения кода, но все еще возникают некоторые проблемы.
В частности, есть опция в мое приложение для связи с Apple Musi c приложением (ранее iTunes), использующим Applescript для связи с ним. До Java 11 это всегда было возможно с помощью libAppleScriptEngine.dylib, который поставляется с MacoS JDK / JRE и яблочным скриптом (изначально предоставляется Apple и предоставляет интерфейс, так что его можно найти с помощью javax.scripting).
In Java 11 libAppleScriptEngine.dylib было удалено, как описано в Oracle JDK 11 Руководство по миграции , без замены.
Удалено ядро AppleScript
Механизм AppleScript, реализация c javax.script, определяемая платформой, был удален без какой-либо замены в JDK.
Механизм AppleScript в большинстве случаев был непригоден для использования в последних выпусках. Функциональность работала только в JDK 7 или JDK 8 на системах, в которых уже была установлена Apple-версия файла AppleScriptEngine.jar.
Однако, если я разверну свое приложение с libAppleScriptEngine.dylib в MacOS папка моего пакета appleScript продолжает нормально работать на Java 11.
Но, к сожалению (хотя проверка подписи приложения не дает ошибок) нотариальное завершение завершается с ошибкой
{
"logFormatVersion": 1,
"jobId": "224840dd-15ec-45a2-8cd0-b046dab3bccb",
"status": "Invalid",
"statusSummary": "Archive contains critical validation errors",
"statusCode": 4000,
"archiveFilename": "songkong-osx.dmg",
"uploadDate": "2020-04-14T11:50:17Z",
"sha256": "b4d3a808a11a342b748901e5b6df5d628fb76a936ebe67ed5b2558cee5f268f7",
"ticketContents": null,
"issues": [
{
"severity": "error",
"code": null,
"path": "songkong-osx.dmg/SongKong.app/Contents/MacOS/libAppleScriptEngine.dylib",
"message": "The binary uses an SDK older than the 10.9 SDK.",
"docUrl": null,
"architecture": "x86_64"
}
]
}
Так есть ли способ обойти это?
Это конец сценария сборки
export CODESIGN_ALLOCATE="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate"
/usr/bin/codesign --timestamp --options runtime \
--entitlements /Users/paul/code/jthink/songkong/songkong.entitlements \
--sign "Developer ID Application: P Taylor" \
--force --deep --verbose /Applications/SongKong.app
/usr/bin/codesign -vvv --deep --strict /Applications/SongKong.app
spctl -a -t exec -vv /Applications/SongKong.app
cd /Users/paul/code/jthink/SongKong
/usr/local/bin/dmgcanvas /Users/paul/code/jthink/SongKong \
/dmgCanvas_songkong.dmgCanvas /Users/paul/songkong-osx.dmg \
-v SongKong -identity "Developer ID Application: P Taylor"\
-notarizationAppleID paultaylor@jthink.net \
-notarizationPassword password -notarizationPrimaryBundleID songkong
Я попытался заменить версию libAppleScriptEngine.dylib на одну из последних Oracle Java 8 build Oracle 8u241 но без разницы. Я удивлен, что он построен на старом sdk, потому что я слышал, что теперь можно нотариально заверять сборку Java 8.
Можно ли не подписывать файл libAppleScriptEngine.dylib, чтобы разрешить нотариальное заверение преуспеть?