Maven LangChain4j SNAPSHOT 找不到：检查 BOM 与 beta 版本

Maven 能下载某些 LangChain4j SNAPSHOT 模块，却找不到同一后缀的 BOM 或 OpenAI 模块，报 Non-resolvable import POM，随后提示 This failure was cached in the local repository。先核对每个 artifact 的确切版本；同一个项目中的所有模块，不一定共用相同 beta 后缀。

例如 1.4 开发阶段，部分模块使用 1.4.0-beta10-SNAPSHOT，但 langchain4j-bom 与 langchain4j-open-ai 对应的是 1.4.0-SNAPSHOT。把可下载模块的版本字符串机械复制给全部模块，会请求一个没有按该坐标发布的 POM。这个历史版本差异不能用来断言当前开发快照仍保留同样命名。

按完整坐标定位缺失项

从首次失败中取出 groupId、artifactId、类型、版本和 Maven 实际访问的仓库。BOM 的类型为 pom，无法解析它时，后续依赖管理和项目模型都可能失败，不能只关注 JAR 是否存在。

区分三种情况：目标坐标本身不对；坐标正确但目标仓库未发布或不允许访问；目标后来可用了，但本机仍保留此前的找不到结果。另一模块下载成功，只能说明它自己的坐标及访问路径可用，不能证明整套模块已经按同一个版本发布。

还应核对当前 POM、父 POM、属性和 profile。依赖版本可能被公共属性拼成统一后缀，也可能显式覆盖了 BOM 中的管理值。错误日志里的实际版本，比变量名字叫 snapshotVersion 更有意义。

用对应 BOM 管理模块组合

先选择项目准备使用、并已确认支持和发布的版本组合，再采用它对应的 BOM。下面是结构片段，langchain4j.bom.version 必须由项目已有的 properties 或父 POM 设置为确认过的 BOM 版本，不能把占位名称当成可下载版本：

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>dev.langchain4j</groupId>
            <artifactId>langchain4j-bom</artifactId>
            <version>${langchain4j.bom.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

将这段合并到原有结构，保留项目的其他 dependencyManagement。被该 BOM 覆盖的实际依赖，通常不再另写一个从其他模块猜来的版本；未覆盖的模块则按自己的发布与兼容要求声明。

历史 1.4.0 正式 BOM 本身为 1.4.0，但其中仍有部分模块使用 1.4.0-beta10，另一些使用 1.4.0。这说明 BOM 管理的是兼容组合，并不承诺所有 artifact 版本字符串都相同。不要为了视觉统一覆盖它的管理结果。

从 SNAPSHOT 改到正式发行版，还会改变代码和依赖行为，需要按项目支持范围评估。旧开发快照可能不再可用，不能把调整为某个历史 SNAPSHOT 当成永久下载保证。

正确坐标仍失败，再看仓库与缓存

SNAPSHOT 需要 Maven 实际使用的仓库允许快照。镜像和认证也会影响访问；POM 中配置了一个仓库，不代表最终解析一定直接访问它。核对 settings.xml、当前激活配置及首次错误，不在日志或公开终端中输出凭据。

Maven 3 会缓存“找不到”的解析失败，并用相应的 .lastUpdated 信息记录失败仓库。缓存消息不是另一项独立的发布故障，也不能证明仓库后来已经补齐。

确认坐标与远端发布状态正确后，可以在原来获准的构建环境强制重新检查。以下只是命令结构，应保留项目原来的目标、profile、settings 和其他必要参数：

mvn -U validate

-U 会检查缺失的 release 和更新的 SNAPSHOT；validate 只到项目校验阶段，不替代后续编译和测试。构建仍可能下载插件、写入缓存或执行项目绑定的目标，应在正常开发或 CI 环境运行。

如果原来已经使用 -U，仍从目标仓库得到找不到，继续查真实坐标和发布状态，不把加第二次 -U 当作修复。内部仓库代理还可能保留自己的否定缓存，本机强制检查不会自动清掉服务端状态，应由仓库管理员按对应策略处理。

不清空整份本地仓库来掩盖版本错误

删除整个 .m2/repository 不会让错误版本的 artifact 出现在远端，却会丢掉其他项目的可用缓存和本地安装制品，增加下载与恢复成本。先修正声明；确有损坏或残留时，再限定到已确认的条目按项目流程处理并保留恢复材料。

变更前保存 POM、锁定或版本记录、仓库配置及本次错误。在原入口确认 BOM 成功解析，模块采用预期的管理版本，再完成项目要求的构建和功能测试。仅不再看到 cached 提示，不代表模块组合已经正确。

需要回退时恢复此前确认可构建的坐标组合与配置，不要还原到原本就不存在的版本。依赖版本回退也不会自动回退已部署应用，应按项目发布与兼容流程处理。