好问题！我没有一个完美的答案，但希望以下仍然会有所帮助。

建议的方法

我会将依赖于生成的api的模块的构建与生成api的构建完全分开。此类生成之间的唯一连接应该是依赖关系声明。这意味着，您必须手动确保先构建api生成项目，然后才构建依赖项目。
默认情况下，这意味着在构建依赖项目之前也要发布api模块。这种默认设置的替代方法实际上是组合构建，例如，允许您在发布新生成的api之前先在本地测试它。但是，在创建/运行复合构建之前，您必须在每次openapi文档更改时手动运行api生成构建。

示例

假设您有一个项目，具体取决于生成的api。它的渐变结构将包含如下内容：

dependencies {
    implementation 'com.example:api:1.0'
}

在运行a的构建之前，首先必须运行 ./gradlew openApiGenerate 从你的 api 项目。 ./gradlew publish 从 api/build/generated/ 目录。
然后，a的构建可以从发布存储库中获取已发布的依赖项。
或者，您可以在本地删除步骤2，并使用附加的gradle cli选项运行a的构建：

./gradlew --include-build $path_to/api/build/generated/ …

减少体力劳动的想法

我想了很多，但没有想出任何完整的解决方案-因此我不完美的建议上面。让我总结一下我的想法。
您将拥有一个gradle构建，它生成api–类似于 api 项目。这个版本也会被提交给你的风投。
该构建将发布生成的api，即使它本身不会生成它。相反，它将以某种方式委托给 openApiGenerate 任务。代表团必须通过 GradleBuild 任务。
关键在于：必须通过gradlecli有效地检索有关依赖项和已发布工件的所有信息。我怀疑这目前是可能的。
依赖于api的项目可以包括 api -就像gradle项目中的一个复合构建，而不需要上述方法的手动麻烦。

以@chriki的答案展开我实际使用的内容：
定义 api/ 因为这是一个空的项目 api/settings.gradle 文件。
这告诉gradle这是一个独立的项目。
使用以下内容定义api模块：

# api/build.gradle

plugins {
   id 'java'
   id "org.openapi.generator" version "5.0.0"
}

repositories {
   mavenCentral()
}

openApiGenerate {
   generatorName = "java"
   inputSpec = "$projectDir/src/main/openapi/specification.yaml"
   outputDir = "$buildDir/generated"
   apiPackage = "com.example.api"
   invokerPackage = "com.example.api.invoker"
   modelPackage = "com.example.api.model"
   configOptions = [
      dateLibrary: "java8",
      library    : "native"
   ]
   groupId = "com.example"
   id = "api"
   version = "1.0.0"
}

注意 group 以及 id （和 version )显式定义其maven坐标。
包含包含替换的构建，以便依赖项可以使用其maven坐标：

# settings.gradle

includeBuild('api/build/generated') {
    dependencySubstitution {
        substitute module('com.example:api') with project(':')
    }
}

... 在其他模块中：

# app/build.gradle

dependencies {
   implementation group: 'com.example', name: 'api'
}

它的主要优点是 ./gradlew --include-build api/build/generated 是不是我的ide也会把它“链接”起来。
生成api库：

./gradlew --project-dir api/ openApiGenerate

构建/运行主项目：

./gradlew build
 ./gradlew run