Gradle Stub

使用 ApiHug stub 任务，把已准备好的 proto 模块生成到应用侧脚手架。

stub 是 ApiHug Gradle 工具链里偏应用侧的生成任务。（已移除，wire包含）

它是什么

它会消费 proto 模块，并生成后续手写业务代码所依赖的应用层脚手架。

为什么重要

stub 是 contract-first 设计变成可运行应用结构的关键一步，也是“哪些代码是生成的、哪些代码应该手写”的边界显形之处。

它如何融入整体流程

基础插件配置

Groovy

plugins {
  id "java"
  alias(libs.plugins.springBoot)
  alias(libs.plugins.springDependency)
  alias(libs.plugins.hopeStub)
  alias(libs.plugins.liquibase)
}

hopeStub {
  debug = false
}

常用 `hopeStub` 选项

选项	说明
`debug`	只做配置检查，不继续生成
`verbose`	输出详细执行日志
`generatedVersion`	在生成元数据中记录插件版本
`generatedTime`	在生成元数据中记录生成时间
`enableFrontVue`	生成实验性的前端脚手架

`hope-stub.json` 关键字段

字段	说明
`packageName`	应用模块 Java 包根
`name`	应用模块名
`domain`	主业务域
`proto.artifact.*`	本服务 proto 依赖坐标
`proto.module`	本地契约的运行时模块名
`proto.domain`	本地契约所属 domain
`proto.applied`	该依赖是否已在 Gradle 中引入
`dependencies.*`	可选的第三方 proto 依赖

依赖管理尽量保持一种方式。除非有明确原因，否则不要把手写 Gradle 依赖和相互冲突的 hope-stub.json 配置混用。

如何执行

和 wire 不同，stub 通常需要显式触发：

Terminal

gradlew {YOUR_MODULE}:clean stub build -x test -x stubTest

下一步

stub 跑完之后，业务逻辑只写在允许手写的层里，然后用 Implementation Review 做检查。