manage-api-version

manage-api-version

读取和更改 Mule 项目中一个或多个 API 依赖项的版本——这些值与 Anypoint Studio Project Properties → API Specs tab 中设置的值相同。项目中的每个 API 依赖项在 pom.xml 中都有自己的版本属性，命名方式为依赖项的 artifactId 加上 .version：

<properties>
  <order-api.version>1.0.0</order-api.version>
  <customer-api.version>2.1.0</customer-api.version>
</properties>

---

概述

此技能会读取和更新 pom.xml 中的 <{artifactId}.version> 属性。Mule 项目可以有一个或多个 API 依赖项，每个依赖项都有自己的版本属性。属性名称始终为 {artifactId}.version，其中 artifactId 是 API 依赖项的 Maven 构件 ID。

你将执行的操作： 显示所有 API 版本或按名称显示特定版本，检查是否有更新版本可用（适用于所有 API 或指定 API），或者在单次操作中更新一个或多个 API 依赖项的版本，并在应用所有更改后重新搭建项目。

---

先决条件

开始前，请确认以下工具可用：

anypoint-cli-v4 --version   # must be v4; needs exchange asset list
mvn --version               # Maven 3.6+ for rescaffold (CHANGE path only)

如果缺少 anypoint-cli-v4：

npm install -g @mulesoft/anypoint-cli-v4
anypoint-cli-v4 conf username <username>
anypoint-cli-v4 conf password <password>

CHECK 和 CHANGE 路径会查询 Exchange。如果 CLI 未通过身份验证或网络不可用，仍可执行仅显示的操作（DISPLAY ALL、DISPLAY SPECIFIC）——这些操作只会读取 pom.xml。

---

随附脚本

此技能在其自身的 scripts/ 目录中提供了一个 shell 辅助脚本：

脚本	用途
scripts/fetch_versions.sh <groupId>:<artifactId>:<currentVersion> [...]	在一次调用中解析一个或多个 API 依赖项的完整已发布版本列表，并行对每个 API 执行一次 Exchange 查询，而不是由 Agent 循环操作、依次为每个 API 调用一次 anypoint-cli-v4。完整用法和输出格式请参阅步骤 7b 中的 版本发现。

请使用 Bash 工具，并通过“技能现已激活”消息中提供的绝对路径调用此脚本（即包含此 SKILL.md 的目录）——例如 <skill-dir>/scripts/fetch_versions.sh ...。请勿构造相对的 ../scripts/... 路径；工作目录会随轮次变化，相对路径会失效。

---

执行路径

用户意图	路径
显示/检查当前版本——所有 API，或未指定具体 API	→ DISPLAY ALL（步骤 1 → 2 → 3）
显示/检查当前版本——已指定一个或多个 API	→ DISPLAY SPECIFIC（步骤 1 → 2 → 4）
检查是否有任何新版本/更新版本可用——未指定具体 API	→ CHECK ALL（步骤 1 → 2 → 5）
检查是否有任何新版本/更新版本可用——已指定一个或多个 API	→ CHECK SPECIFIC（步骤 1 → 2 → 6）
设置、更改、调整、更新、升级或切换版本	→ CHANGE（步骤 1 → 2 → 7 → 8 → 9）

---

步骤 1：解析项目目录

按以下优先顺序，使用最佳可用信号解析项目根目录：

1. 提供了确切路径 — 直接使用。
2. 给出了大致位置或文件夹名称（例如“order-api 项目”“在我的文档里”“在 ~/projects 里的那个”）— 使用 find 查找与提示匹配的 pom.xml；如果找到多个匹配项，请向用户确认。
3. 有多个已打开/在范围内的项目，且用户给出了 API 名称，但没有项目提示（例如多根工作区，或根据上下文可访问多个 pom.xml）— 在退回到“当前/活动项目”之前，检查已打开项目的 pom.xml 中，是否只有一个项目包含所指定 API 的 <{artifactId}.version> 属性（或匹配的硬编码 <dependency> artifactId：
   • 唯一匹配 — 静默使用该项目。不要询问；名称只在一个地方出现，实际上并不存在歧义。
   • 匹配多个项目 — 按照下面的案例 5 询问用户选择哪个项目。
   • 已打开的项目中均无匹配项 — 不要询问“哪个项目”（这会让人以为问题出在项目上，而实际上更可能是 API 名称有误）。应改为说明：

     我在任何已打开的项目（<列出已打开项目名称/路径>）中都找不到名为 <name> 的 API。你指的是其他 API 名称，还是该 API 所在的项目目前未打开？ 只有当确实有 2 个或更多项目在范围内时才进行此检查。如果只有一个已打开/可访问的项目，则直接跳到案例 4——没有需要消除的歧义时，绝不要询问。

4. 暗示使用当前工作目录（例如“这个项目”“当前这个项目”），或只有一个项目在范围内 — 检查当前目录下是否存在 pom.xml，并使用该目录。
5. 没有提供任何信息——既没有项目提示，也没有可用于消除歧义的 API 名称——且有多个项目在范围内 — 这包括“更新 API 版本”或“检查更新”这类完全通用的请求：如果有 2 个或更多已打开的项目，且在本次对话中尚未确定项目，则属于此情况。不要在这种情况下猜测“当前目录”，即使某个目录在技术上处于活动状态（例如最后获得焦点的文件标签页所属目录）——没有给出名称或路径的通用请求，正是本步骤旨在处理的歧义情况。请询问：

你想处理哪个项目？可以提供完整路径、文件夹名称，或者直接告诉我这是当前目录。

继续之前，请确认解析出的路径下存在 pom.xml。

每次对话最多询问一次。 用户说明或确认项目后，在本次对话后续请求中继续使用该项目——不要每轮都重新询问。如果用户之后指定了其他项目，或指定了一个解析到其他项目的 API，则静默切换，并在回复中确认切换（例如“本次切换到 <project>。”），而不是重新进行完整的消歧提问。

停止（仅在无法根据上下文解析项目时）。

---

步骤 2：路由操作

根据用户请求中的意图关键词进行解析：

关键词	操作
get、show、find、display、what is、current — 所有 / 每个 / 未指定具体 API	→ 显示全部
get、show、find、display、what is、current — 指定了一个或多个 API	→ 显示指定项
any new、updates、newer、latest、upgrade — 未指定具体 API	→ 检查全部
any new、updates、newer、latest、upgrade — 指定了一个或多个 API	→ 检查指定项
set、change、adjust、update、bump、switch	→ 更改

如果意图不明确，请询问：

你想显示当前 API 版本，还是更改版本？

停止（仅在无法根据请求确定操作时）。

---

第 3 步：显示所有 API 版本（显示全部）

1. 读取 pom.xml。查找 <properties> 中名称以 .version 结尾、且对应 API 规范依赖项的所有属性。要识别 API 规范依赖项，请检查对应的 <dependency> 块：
   • 检查 classifier（优先）： API 规范依赖项使用以下 classifier 之一：raml、oas、graphql、protobuf、fat-protobuf、evented-api。连接器使用 mule-plugin。如果存在 classifier 且与此列表匹配，则该依赖项是 API 规范。
   • artifactId 备选判断： 如果未设置 classifier，请检查 artifactId 是否包含单词 api——这是 API 规范制品的常见命名约定。 跳过 classifier 为 mule-plugin 或两种判断方式都不匹配的依赖项。
2. 打印所有匹配项：

API dependency versions (from pom.xml <properties>):

  order-api.version    → 1.0.0
  customer-api.version → 2.1.0

3. 如果未找到任何项，请明确说明，并建议用户在 Anypoint Studio 的 Project Properties → API Specs 选项卡中检查是否已将 API 添加到项目中。

对于“显示全部”路径，到此结束此技能。

---

第 4 步：显示指定 API 的版本（显示指定项）

1. 提取用户指定的所有 API 名称。如果没有指定名称，则回退到“显示全部”。
2. 读取 pom.xml。对于每个指定的 API，查找其 <{artifactId}.version> 属性。
3. 打印每项结果：

order-api.version    → 1.0.0
customer-api.version → 2.1.0

4. 如果未找到某个指定 API 的属性，请标明这一点，并列出可用的 API 版本属性，以便用户确认正确的名称。

对于“显示指定项”路径，到此结束此技能。

---

第 5 步：检查所有 API 是否有更新版本（检查全部）

1. 读取 pom.xml，并识别所有 API 规范依赖项（使用与“显示全部”相同的 classifier/artifactId 判断逻辑）。

2. 对于每个 API，使用下方的版本发现流程查找其完整版本列表。

3. 报告结果：

   如果任何 API 存在更新版本：

   Newer versions available:
   
     order-api:    current 1.0.0 → latest 2.0.0
     customer-api: current 1.5.0 → latest 1.6.0
   
   No updates available:
     billing-api: 3.1.0 (already latest)
   
   Would you like to update any of these?
   

   停止——如果用户想要更新，则从第 7 步开始，针对用户指定的 API 转到“更改”路径。

   如果所有 API 都没有更新版本：

   All APIs are on their latest versions:
   
     order-api:    1.0.0
     customer-api: 2.1.0
     billing-api:  3.1.0
   
   Would you like to change any version anyway?
   

   停止——如果用户想要更新，则转到第 7 步的“更改”路径。

如果用户不想进行任何更改，到此结束此技能。

---

第 6 步：检查指定 API 是否有更新版本（检查指定项）

1. 提取用户指定的 API 名称。

2. 对于每个指定的 API，使用下方的版本发现流程查找其完整版本列表，并与当前版本进行比较，以确定是否存在更新版本。

3. 按用户提出的顺序，逐个处理指定的 API：

   如果存在更新版本：

   order-api — current: 1.0.0
   A newer version is available: 2.0.0
   
   Would you like to update it?
   

   停止——如果用户想要更新，则继续此 API 的“更改”流程（从第 7c 步开始）。如果不想更新，则转到下一个指定的 API。

   如果已经是最新版本：

   order-api is already on the latest version: 1.0.0
   
   Would you like to change it to a different version anyway?
   

   停止——如果用户想要更新，则继续此 API 的“更改”流程（从第 7c 步开始）。如果不想更新，则转到下一个指定的 API。

4. 处理完所有指定的 API 后，如果有任何 API 已列入待更改项，则继续执行第 8 步。

---

第 7 步：确定目标 API 并获取可用版本（更改）

7a — 确定要更改的 API

如果用户指定了要更新的 API，则使用这些 API。否则：

1. 读取 pom.xml，并列出所有 API 依赖项的版本属性。
2. 询问用户想要更新哪些 API。

停止（仅当目标 API 未预先指定时）。

7b — 从 Exchange 获取可用版本

查询前，先在内存中备份当前 pom.xml 内容，以便之后发生故障时恢复。

从 pom.xml 中每个目标 API 的 <dependency> 块读取 groupId 和 artifactId，然后按照下方的版本发现流程，通过单次调用发现它们的所有版本列表——将所有目标 API 作为单独参数传给同一次脚本调用，绝不能每个 API 调用一次。

如果任何一行返回 "source": "error"（该 API 的 list 和 describe 回退操作均失败）：

• 如果尚未修改 pom.xml，则停止并告知用户，同时引用该行的 error 字段：

  无法从 Exchange 获取 <artifactId> 的版本。请检查 anypoint-cli-v4 是否已通过身份验证，以及是否可以访问网络，然后重试。

• 如果此前的步骤已部分修改 pom.xml，则先恢复到备份状态，再停止并显示相同的消息。

---

版本发现（共享流程 — 步骤 5、6、7b 使用）

通过一次调用捆绑脚本发现所有目标 API 的版本——绝不要循环并自行逐个 API 调用 anypoint-cli-v4。 每次直接调用 anypoint-cli-v4 都要支付一次完整的 Node CLI 冷启动和网络往返开销；如果对每个 API 都循环调用，就会串行执行 N 次网络往返，而一次脚本调用会并行执行所有调用并在完成后一次性返回。对于包含多个 API 依赖项的项目，这是让此技能响应更快的最大因素。

使用 Bash 工具，通过脚本的绝对路径调用脚本——<skill-dir>/scripts/fetch_versions.sh，其中 <skill-dir> 是你在“技能现已激活”消息中收到的绝对路径（包含此 SKILL.md 的目录）。不要构造相对路径 ../scripts/...；工作目录会随对话轮次改变，相对路径可能失效。

为每个目标 API 传入一个 <groupId>:<artifactId>:<currentVersion> 参数——步骤 5 和 6 传入该步骤中识别出的所有 API；步骤 7b 传入变更集中的所有 API：

<skill-dir>/scripts/fetch_versions.sh \
  "<groupId1>:<artifactId1>:<currentVersion1>" \
  "<groupId2>:<artifactId2>:<currentVersion2>"

脚本会向 stdout 打印一个 JSON 数组，每个输入 API 对应一个对象，顺序与输入一致：

[
  {
    "groupId": "org.example", "artifactId": "order-api", "currentVersion": "1.0.0",
    "versions": ["2.0.0", "1.1.0", "1.0.0"],
    "source": "list"
  }
]

读取每一行的 source 字段：

• "list" — 正常路径。脚本内部运行了 exchange asset list <artifactId> --output json，筛选出与确切 groupId/assetId 匹配的行，并按 semver 降序排序（最高版本优先）。请完全信任此结果——它不依赖任何单一版本，因此不存在下文所述的漏报问题。
• "describe-fallback" — list 未返回此资源的任何匹配行，因此脚本回退到 exchange asset describe <groupId>/<artifactId>/<currentVersion> 并解析其 otherVersions 字段。将该行的 warning 字段原样告知用户——describe 返回的版本列表依赖于所查询的版本；据观察，如果该锚定版本不是最新发布版本，即使确实存在更新版本，返回的列表也可能为空。由于 CHECK/CHANGE 总是从 pom.xml 当前固定的版本开始查询（几乎从来不是最新版本），因此应将此行的版本列表视为可能不完整。
• "error" — 此资源的 list 和 describe 回退操作均失败。告知用户该行的 error 字段。对于步骤 7b（CHANGE），按 Exchange 获取失败处理（见下文）。对于步骤 5/6（CHECK），报告该特定 API 的失败，并继续处理其他 API——不要因为一个 API 查询失败就中止整个检查。

（这与此仓库中两个同级技能采用的模式一致——build-mule-integration/scripts/search_templates.sh 和 manage-global-configurations/scripts/get_latest_connector.sh——它们出于同样的延迟原因，会并行调用多个 exchange asset list，而非顺序循环调用。）

7c — 展示可用版本并处理选择

对于每个目标 API，请通过一次 AskUserQuestion 工具调用展示可用版本；不要先在普通聊天文本中叙述版本列表，然后再调用工具，否则同一个问题会呈现两次。工具调用本身就是唯一的展示方式。如果存在比当前版本更新的版本，请在问题文本中提及；将所有可用版本列为选项（包括已标注的当前版本），无需提供类似“保持当前版本”的选项，因为当前版本已在列表中：

question: "order-api — current: 1.0.0. A newer version is available: 2.0.0. Which version would you like to use?"
options:
  - "2.0.0"
  - "1.1.0"
  - "1.0.0 (current, no change)"
  - "0.9.0"

如果当前版本已经是最新版本，请从问题文本中删去“有更新版本可用”的句子，但仍按相同方式调用工具：

question: "order-api — current: 2.0.0. Which version would you like to use?"
options:
  - "2.0.0 (current, no change)"
  - "1.1.0"
  - "1.0.0"

需要更改多个 API 时，请逐个处理：先针对第一个 API 调用一次 AskUserQuestion，然后停止并获取选择，再处理下一个 API，并再次调用新的 AskUserQuestion。

停止 — 在展示下一个 API 之前，等待工具返回当前 API 的结果。绝不要在工具调用前后通过单独的聊天消息重述问题或选项列表。

7d — 处理选择相同版本的情况

如果用户为某个 API 选择的版本与已应用的版本相同，请回复：

order-api 当前已使用版本 1.0.0 — 未作任何更改。

从变更集中移除该 API。如果请求中的所有 API 都无需更改，请在此结束此技能。否则，继续处理确实需要更改版本的 API。

---

第 8 步：应用新版本（更改）

8a — 更新 pom.xml

对于变更集中的每个 API，判断适用以下哪种情况：

情况 1 — 已存在属性占位符（<{artifactId}.version> 位于 <properties> 中）： 更新 <properties> 块中的值。依赖项本身（<version>${order-api.version}</version>）无需更改。

ARTIFACT_ID="order-api"
NEW_VERSION="1.1.0"

awk -v key="${ARTIFACT_ID}.version" -v val="$NEW_VERSION" '
  $0 ~ "<" key ">" { sub(/>.*</, ">" val "<") }
  { print }
' pom.xml > pom.xml.tmp && mv pom.xml.tmp pom.xml

情况 2 — 版本直接硬编码在依赖项中（不存在 <{artifactId}.version> 属性，且依赖项包含字面值 <version>1.0.0</version>）： 这意味着项目尚未使用占位符模式。执行以下两项操作：

1. 在 <properties> 块中添加 <{artifactId}.version>NEW</{artifactId}.version>。
2. 将该依赖项块中的硬编码 <version>1.0.0</version> 替换为 <version>${order-api.version}</version>。

对变更集中的每个 API 重复此操作，并在写入文件之前完成所有编辑。

8b — 确认

打印所有已完成更改的摘要：

Updated in pom.xml:
  order-api.version:    1.0.0 → 1.1.0
  customer-api.version: 1.5.0 → 2.0.0

---

第 9 步：重新生成项目脚手架（变更）

更新完所有版本属性后，触发 APIkit，根据新版 API 规范重新生成流程——这与 Anypoint Studio 在你保存 Project Properties → API Specs 选项卡中的更改时执行的操作相同。如果在同一操作中更改了多个 API，则会在这一次操作中重新生成所有这些 API 的流程。

在项目根目录中按如下所示运行命令——只能有这两条命令，并用 && 连接，后面不得追加任何内容：

cd <projectDir> && mvn clean package -DskipTests

• 切勿在此命令后追加 2>&1、>、>> 或任何其他重定向，也不得将其通过管道传递给其他内容。 工具调用已完整捕获标准输出和标准错误，因此重定向毫无作用——而且会产生实际副作用：宿主 IDE 的命令层会将流重定向运算符视为不安全，即使命令本身已获信任，也会强制弹出手动批准提示，这正是此步骤必须避免的情况。
• 不要添加标志，也不要将它与其他内容打包——只能使用上面 cd <projectDir> && mvn clean package -DskipTests 的确切格式。
• 运行前不要暂停等待用户确认。 在实际产品中，版本更改后会自动重新生成脚手架——Anypoint Studio 会在 pom.xml 更改时，或用户触碰 Project Properties → API Specs 选项卡时立即运行，不需要人工点击确认。此技能遵循相同的流程：第 8 步的编辑写入后，立即运行命令，不要询问。
• 等待完整输出后再继续。
• BUILD SUCCESS 表示 APIkit 已载入更新后的规范版本并重新生成相应流程。现在，项目已与所有更改后的 API 版本保持一致。
• 如果出现 BUILD FAILURE：自动将 pom.xml 恢复到更改前的状态，然后逐字报告 Maven 错误输出，供用户排查：

  构建失败 — pom.xml 已恢复到之前的状态。Maven 错误：[此处为输出内容]

每次回复只能调用一次 mvn。 不要将其与任何其他工具调用打包。

---

规则

• 属性名始终为 {artifactId}.version — 根据 API 依赖项的 Maven artifactId 推导，不能使用 <apiVersion> 这类硬编码标签。
• 绝不修改 <version>（pom.xml 顶部的 Maven 构件版本）。这是完全不同的字段。
• 应用更改前始终先显示可用版本。 绝不让用户输入版本字符串 — 始终先从 Exchange 获取版本列表并展示。
• 仅在存在更新版本时提示。 只有当前版本不是最新版本时，才显示“有更新版本可用”的消息。否则绝不显示。
• 相同版本属于无操作，不是错误。 如果用户选择了已应用的版本，说明这一点，并将该 API 从变更集里排除。如果所有选择都属于无操作，则结束，不写入任何文件，也不运行 mvn。
• 批量应用所有更改，然后只重新脚手架一次。 运行 mvn 前先应用所有 pom.xml 编辑。绝不要在单个 API 更新之间重新脚手架 — 最后运行一次 mvn 即可处理所有更改。
• 写入前始终备份 pom.xml。 每次 CHANGE 操作开始时，将原始内容保存在内存中。发生任何导致操作无法成功完成的失败时 — 无论是 Exchange 获取错误、mvn 失败还是其他错误 — 都自动还原文件。
• 每次 CHANGE 后都必须重新脚手架，且必须自动执行 — 绝不询问用户。 未运行 mvn clean package -DskipTests 并确认 BUILD SUCCESS 前，绝不声称版本已更新。版本更改后若不重新脚手架，项目将处于不一致状态。Step 8 的编辑完成后立即运行，不要询问确认；这与 Anypoint Studio 在 pom.xml 更改或 API Specs 选项卡编辑后自动重新脚手架的行为一致。
• 绝不重定向 mvn 命令的输出。 不得使用 2>&1、>、>> 或管道 — 工具调用已捕获完整的 stdout/stderr，重定向运算符可能触发宿主 IDE 的不安全命令检查，导致必须进行不必要的手动审批。
• 每次回复最多调用一次 mvn。 不要将其与文件编辑或其他命令捆绑执行。
• 编辑 pom.xml 无需 Anypoint CLI — 只使用 bash 和 Read/Edit 工具。
• 解析 Exchange JSON 响应时，scripts/fetch_versions.sh 需要 jq。 如果运行脚本的机器上没有 jq，脚本就会失败 — 没有单独的手动备用方案；应安装 jq，不要在脚本中内联重写解析逻辑。
• 版本发现始终通过一次 scripts/fetch_versions.sh 调用覆盖所有目标 API，绝不能对每个 API 循环调用原始 anypoint-cli-v4。 参见 Step 7b 下的 Version Discovery 流程。该脚本会并行对所有目标 API 运行 exchange asset list（不锚定版本）；只有当 list 未找到某个资源的匹配项时，才会针对该 API 回退使用 exchange asset describe 的 otherVersions 字段 — describe 返回的版本列表锚定于查询时所用的版本；已观察到当该版本不是最新版本时，它会返回空列表或不完整结果，而 CHECK 和 CHANGE 正是在这种情况下进行查询。
• 多 API 版本选择必须逐个进行。 展示一个 API 的版本列表后，停下来等待用户选择，然后再继续下一个。绝不要同时展示所有列表。
• 多轮交互。 遇到每个 STOP 标记时：只以纯文本输出问题，然后结束回复并等待。所有必需值收齐之前，不要运行任何工具。
• 已提供值则跳过。 首次 STOP 前，提取用户已提供的值（项目路径、操作、目标 API、新版本）。遇到每个 STOP 时，如果问题已有答案，就跳过。

---

故障排除

• 未找到 .version 属性： 这些 API 可能尚未添加到项目中。使用 Anypoint Studio 的 Project Properties → API Specs 选项卡先添加 API 依赖项，这会在 pom.xml 中创建相应属性。
• 更改版本后 mvn 失败： pom.xml 会自动还原。查看 Maven 错误以了解根本原因——所选版本可能存在不兼容的依赖项，或者 Exchange 资源尚未完全发布。
• 同一 API 存在多个属性： 如果同一个 artifactId 在 <properties> 下出现多次，请更新所有对应项，以保持项目一致。
• scripts/fetch_versions.sh 返回的行因身份验证错误而显示 "source": "error"： 运行 anypoint-cli-v4 conf 验证凭据，或重新进行身份验证：anypoint-cli-v4 conf username <user> / anypoint-cli-v4 conf password <pass>。如果环境中设置了 ANYPOINT_BEARER，同时还设置了 ANYPOINT_CLIENT_ID/ANYPOINT_CLIENT_SECRET，请取消设置客户端凭据变量——同时启用多种身份验证方式时，CLI 会拒绝调用。
• 某行返回 "source": "describe-fallback"，且 versions 列表看起来过短： 这是预期行为——exchange asset list 未找到与该 groupId/assetId 对应的行，因此脚本改用以版本为锚点的 describe 查询；这可能会漏报比当前版本更新的版本（参见 版本发现）。请确认 artifactId 与 Exchange 的 assetId 完全一致（区分大小写），并确保账号已通过正确的组织进行身份验证——如果私有资源发布在与 CLI 会话所选组织不同的组织下，就不会通过 list 显示。接下来，可以手动运行 anypoint-cli-v4 exchange asset list <artifactId> --output json（不进行筛选），查看该资源是否显示在与 pom.xml 中不同的 groupId 下。
• "source": "error"，但没有明显的身份验证或网络原因： 针对该特定资源，exchange asset list 和 describe 后备查询都失败了。单独通过 scripts/fetch_versions.sh 重新查询该 API，以便更清楚地查看底层 CLI 错误；也可以手动运行这两条 anypoint-cli-v4 命令，直接检查 stderr。

---

相关技能

• manage-global-configurations — 设置 API AutoDiscovery（api.id）和其他与这些 API 版本配套的全局元素
• build-mule-integration — 更改版本后构建并打包 Mule 项目