Maven 3.10 构建后类仍是 final：旧 Kotlin 插件没加载 all-open

升级 Maven 3.10.0 后，旧 Kotlin 项目仍能生成 JAR，Spring 启动时却说配置类不能是 final。即使日志打印了 Applied plugin: 'spring'，也要检查 all-open 编译插件是否真的进入编译器的插件类路径。

旧 kotlin-maven-plugin 与 kotlin-maven-allopen 1.5.30 有过明确表现，附近日志是本地 JAR 已存在，但来源仓库 ID 不在当前请求上下文，随后显示 verifying that is downloadable from []。空列表尤其值得注意：插件解析自己的编译插件依赖时，没有给出可用的远程仓库列表。

本地有 JAR 不代表本次请求可以使用

Maven 的增强本地仓库管理会记录缓存制品来自哪个远程仓库。插件请求里没有那个仓库，甚至列表为空时，不能只凭磁盘上找到同名 JAR 就认定解析成功。旧插件还可能继续构建，却没有把缺失 JAR 加入编译器参数，使本应被 all-open 打开的 Kotlin 类仍保留 final。

先核对实际 Maven、Kotlin Maven 插件及 all-open 版本，保存首次解析提示和最终失败。不要把 Applied plugin 这一行当作字节码已改变的验收证据。清空 .m2 不会让插件自动补上传入请求的仓库信息，还可能丢掉可用缓存与本地安装制品。

使用正确传递插件仓库的版本组合

Kotlin Maven 插件 1.9.0 的正式实现会把当前项目的插件仓库列表和本地仓库传给这条解析请求；旧 1.5.30 的对应实现没有这些设置。项目允许更新时，选择包含该处理、并与项目语言、JDK 和依赖兼容的插件组合，同时对齐 all-open 等编译插件版本。1.9.0 是已核对的实现边界，不是要求所有维护项目固定到这个历史版本。

暂时不能调整 Kotlin 插件的分支，可以保留原先已验证、且仍符合项目维护要求的 Maven 工具链作为过渡。不要把降级写成永久兼容保证，也不要直接编辑 _remote.repositories，伪造制品来源来让校验通过。

通过 simple LRM 互操作并关闭远程过滤，也会改变解析与隐私边界，而且相关互操作开关在过滤仍启用时可能被忽略。这不是可以全局复制的无代价修复；优先修正插件解析请求，而非一并关闭仓库约束。

验收从干净、可重建的项目输出重新编译，检查预期类的字节码是否已去除 final，并启动原来的 Spring 配置与测试。对需要保持 final 的类也要抽查，避免扩大 all-open 注解范围。只有最终类行为和应用启动都符合原意，才证明编译插件真正生效。