桌面应用开发工具【免费下载链接】MooToolHandy tool set for developers项目地址https://gitcode.com/gh_mirrors/mo/MooTool点击查看免费下载本文解读 MooTool 仓库中next-compose产品线的一则架构决策记录 —— ADR-003Intel Mac 上的 Compose 1.12.0。它回答了这样一个工程问题当官方 Compose Multiplatform 1.12.0 的平台支持表只列出 macOS 13 arm64 时在 Intel Core i7x86_64开发机上如何锁定、验证并正确描述自己的工具链状态。读完本文你将掌握 Compose Multiplatform Desktop 跨架构构建时的版本锁定方法、按 OS/arch 选择 Skiko 运行时工件的实现方式以及如何通过 JVM 单测与打包结果建立条件目标的证据边界。一、决策背景官方平台表与开发机架构的错位Compose Multiplatform 1.12.0 官方平台支持表仅列出 macOS 13 arm64 目标。而next-compose产品线当时的开发机是Intel Core i7x86_64运行环境为Zulu JDK 21 x86_64。这意味着该机不在官方 1.12.0 的 macOS 平台目标之内但在 x86_64 上仍可能通过 JVM 依赖解析拿到可用的 Skiko JVM 工件并完成构建与测试。关于官方平台矩阵的处理原则产品线的架构文档有明确交代见 next-compose/docs/architecture.md 第 1 节正式支持矩阵取 Compose、Skiko、JDK、数据库/native helper 的交集当前官方平台表未将 Intel Mac 列入 1.12.0 目标不将其作为已支持平台。若计划兼容 IntelP0 选择明确支持的版本组合并形成单独实验记录。ADR-003 正是这条原则的具体落地产物官方矩阵缺位 ≠ 本地无法开发但本地结果也不能反向宣称官方支持两者必须分开表述。二、决策内容锁定统一版本组合不以本地结果冒充官方支持ADR-003 的决定部分包含三条构成该决策的核心骨架仍锁定 Compose 1.12.0 Kotlin 2.2.21 Gradle 8.14.3 JDK 21以便与规格候选组合保持一致JVM 单测已在该 Intel 机器通过说明依赖解析与 Skiko JVM 工件可用不把本机结果写成 macOS arm64 已支持arm64 需在对应 runner 上构建。2.1 版本组合的仓库落地这一锁定组合不是孤立声明而是完整固化在next-compose的构建脚本中依赖版本目录 next-compose/gradle/libs.versions.toml 中kotlin 2.2.21、composeMultiplatform 1.12.0且同时声明了两个 macOS 桌面运行时工件compose-desktop-macos-x64 { module org.jetbrains.compose.desktop:desktop-jvm-macos-x64, version.ref composeMultiplatform } compose-desktop-macos-arm64 { module org.jetbrains.compose.desktop:desktop-jvm-macos-arm64, version.ref composeMultiplatform }Gradle Wrapper 版本固化在 next-compose/gradle/wrapper/gradle-wrapper.propertiesgradle-8.14.3-bin.zip。产品版本appVersion0.1.0与 JVM 参数固化在 next-compose/gradle.properties。2.2 按运行机器自动选择 Skiko 运行时工件实现Intel Mac 条件目标的关键代码在 next-compose/composeApp/build.gradle.kts 第 2936 行。构建脚本读取os.name与os.arch在构建机器上动态决定使用哪个desktop-jvm-macos-*工件val osName System.getProperty(os.name).orEmpty().lowercase() val osArch System.getProperty(os.arch).orEmpty().lowercase() val desktopNative when { osName.contains(mac) (osArch aarch64 || osArch arm64) - libs.compose.desktop.macos.arm64 osName.contains(mac) - libs.compose.desktop.macos.x64 osName.contains(win) - libs.compose.desktop.windows.x64 else - libs.compose.desktop.linux.x64 }这段代码揭示了一个重要事实Intel Mac 作为条件目标的核心是运行时工件Skiko 原生库按架构选取。同一份jvm(desktop)JVM 目标jvmTarget JVM_21、jvmToolchain(21)在三平台复用不需要为 x86_64 建立单独的 Kotlin/Native 目标。这正对应 next-compose/docs/architecture.md 的约束不要建立macosArm64Kotlin/Native 目标后假定可直接运行同一套 Desktop UI。需要特别说明的是该判断发生在构建打包机器上。也就是说在 Intel Mac 上执行createDistributable得到的 DMG 面向 x86_64arm64 安装包必须在 Apple Silicon 的 runner 上重新构建这正是 ADR 中arm64 需在对应 runner 上构建的底层原因。三、决策的验证依据测试通过 ≠ 运行验收ADR-003 之所以敢写仍锁定而不写已支持是因为它区分了两类证据。3.1 已取得的证据环境记录 next-compose/docs/evidence/2026-09-09-p0-p1/environment.md 明确了本机事实机器macOS Darwin 25.6.0Intel Core i7-1068NG7 x86_64JDKZulu 21.0.12.1构建Gradle Wrapper 8.14.3、Kotlin 2.2.21、Compose Multiplatform 1.12.0。验收记录 next-compose/docs/evidence/2026-09-09-p0-p1/results.md 给出了三条与 ADR-003 直接相关的实测结果命令 / 动作结果./gradlew :composeApp:desktopTest成功13 个测试 0 失败./gradlew :composeApp:createDistributable成功产物composeApp/build/compose/binaries/main/app/MooTool Next Compose.app安装镜像启动进程保持存活创建product.json/ SQLite / vault 目录日志无异常这份记录还详细列明了未测/失败项中文 IME、列编辑、5 MiB 编辑器、分离收回 undo、视觉明暗截图、Windows/Linux 构建、动态 protoc 捆绑、完整 Vault Git、更新通道等。未测项与已测项并列披露正是不以本机结果冒充官方支持的证据纪律。3.2 测试通过说明了什么从源码结构看desktopTest通过至少证明了两件事依赖解析完整Compose 1.12.0 的 x86_64 JVM 工件desktop-jvm-macos-x64在 Maven Central 可解析Skiko JVM 工件可用测试能链接并加载对应架构的 Skiko 原生库。但正如 ADR 措辞的严谨之处——它只写JVM 单测已通过说明依赖解析与 Skiko JVM 工件可用没有声称 Skiko UI 渲染在 x86_64 上已被验收。测试通过不能证明窗口渲染、GPU 合成、输入事件等运行时行为正确。这与 next-compose/docs/architecture.md 的验收要求一致安装包必须执行runDistributable或直接启动镜像验证因为完整 JDK 下run通过不能证明 jlink 后无缺少模块。不要只运行 JVM 单测而跳过 Swing/Compose/安装包行为。四、后果分析条件目标的定义与降级预案ADR-003 的后果部分给出了条件目标的操作性定义Intel Mac 为条件目标。若后续发现 Skiko UI 在 x86_64 运行失败再评估降级 Compose 或仅支持 arm64。这定义了两种未来状态正向路径x86_64 上 Skiko UI 运行正常 → 维持当前锁定组合Intel Mac 作为持续开发目标降级预案若 x86_64 上 Skiko UI 失败 → 两个选项① 降级 Compose 到官方明确支持 Intel 的版本② 放弃 x86_64仅支持 arm64。条件目标的边界价值在于它可以工作但不构成对官方支持矩阵的承诺。发布宣传、issue 模板、用户文档中对 macOS 的支持表述必须与官方矩阵对齐Intel 支持只能作为本地已验证的开发状态出现。4.1 相邻决策jpackage 版本映射的协同约束与 ADR-003 同日记录的 next-compose/docs/adr/001-macos-jpackage-version.md 构成了工具链约束的另一个侧面macOSjpackageJDK 21拒绝--app-version 0.1.0第一个数字不能为零或负数因此安装包元数据映射为1.1.0而 UI /product.json/ Git tag 仍使用appVersion0.1.0。该映射逻辑同样固化在 next-compose/composeApp/build.gradle.kts 第 1219 行val appVersion: String providers.gradleProperty(appVersion).get() val nativePackageVersion: String if (appVersion.startsWith(0.)) { 1${appVersion.removePrefix(0)} } else { appVersion }并配有一条锁定任务verifyNativePackageMetadata同文件第 208227 行在不构建安装包的前提下校验nativePackageVersion映射是否符合预期——这保证了锁定版本组合在 CI 中可被持续回归检查。五、在 Intel Mac 上复现这套工具链验证如果你也持有 Intel Mac可以按next-compose产品线的脚本复现 ADR-003 所述的验证路径。前提是安装 JDK 21cd next-compose export JAVA_HOME$(/usr/libexec/java_home -v 21) ./scripts/check-toolchain.sh # 打印 JAVA_HOME、java -version、Gradle 版本与 printTooling 输出 ./scripts/check-core.sh # 核心检查 MOOTOOL_COMPOSE_DATA_DIR$PWD/local.properties.d/dev-profile ./scripts/run.sh其中check-toolchain.sh会输出printTooling任务的关键信息见 next-compose/composeApp/build.gradle.kts 第 193206 行appVersion、nativePackageVersion、Kotlin/Compose 版本、java.home、java.version、os.name、os.arch——你可以在终端里直接核对os.archx86_64与compose1.12.0是否匹配 ADR-003 的前提。可直接运行的已核实 Gradle 任务./gradlew --version ./gradlew :composeApp:printTooling ./gradlew :composeApp:desktopTest ./gradlew :composeApp:run ./gradlew :composeApp:createDistributable在 Intel Mac 上createDistributable的输出为composeApp/build/compose/binaries/main/app/MooTool Next Compose.appbundle ID 为com.rememberber.mootool.next.compose参见 next-compose/README.md 与 build.gradle.kts 的p7MacBundleId常量。Windows MSI / Linux DEB 需要到对应操作系统执行packageDistributionForCurrentOS这同样体现各架构/平台在各自 runner 上构建的边界原则。六、关键结论与决策清单对希望参考next-compose这条产品线的团队ADR-003 提供了可迁移的决策模板官方矩阵缺位不阻塞开发Compose 1.12.0 未列 Intel Mac但 x86_64 JVM 工件可解析、单测可通过足以支撑开发机上的日常开发版本组合必须整体锁定Compose 1.12.0 Kotlin 2.2.21 Gradle 8.14.3 JDK 21 四者一致避免混入规格外组合插件版本必须同步org.jetbrains.kotlin.plugin.compose与 Kotlin 插件版本一致架构选择交给构建机器通过os.name/os.arch在打包时选择desktop-jvm-macos-x64或desktop-jvm-macos-arm64一份jvm(desktop)目标覆盖三平台测试通过与运行验收分离单测证明依赖与工件可用UI 渲染验收需以runDistributable或安装镜像启动为准后果与降级预案成文明确条件目标的判定条件和两条降级路线降级 Compose 或仅支持 arm64并为版本映射类约束配套自动化锁定任务如verifyNativePackageMetadata。这则 ADR 的价值不在于声明Intel 可用而在于把可用、已支持、官方矩阵三者的边界讲清楚并把验证证据固化在docs/evidence/目录中让后续维护者可以追溯每一次本机通过的真实条件与未覆盖范围。赞分享桌面应用开发工具【免费下载链接】MooToolHandy tool set for developers项目地址https://gitcode.com/gh_mirrors/mo/MooTool点击查看免费下载相关推荐MooTool Next Compose 编辑器宿主架构解析RSyntaxTextArea SwingPanel 的 ADR-002 决策与实践MooTool Next Compose 编辑器宿主架构解析RSyntaxTextArea SwingPanel 的 ADR 002 决策与实践 导读 本桌面应用开发工具MooTool Next Compose用 Compose Multiplatform 构建独立桌面工具集的工程实践MooTool Next Compose用 Compose Multiplatform 构建独立桌面工具集的工程实践 本文基于仓库中的 next compos桌面应用开发工具MooTool Next Compose 验收体系状态规则、DIFF 证据链与 1344 测试基线的复现方法MooTool Next Compose 验收体系状态规则、DIFF 证据链与 1344 测试基线的复现方法 本文以 MooTool Next Compose桌面应用开发工具上一篇10分钟跑通第一个NotebookBeginner-Data-Science-Projects环境搭建与快速开始教程下一篇weathr配置指南config.toml全部设置项详解新手也能玩转自动定位与英制单位创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考