Apache Gump live r1939132 实战与维护状态详解

基于 r1939132 快照剖析 Apache Gump 的实战运行链路（runner 与 actor 体系、update/build 崩溃的代码级根因）与维护状态（README 官方口径、SVN 提交频率实测、官方 vmgump 实例 2026-10-15 当日运行数据），并给出接入现代项目与自建运维的实操建议，全部结论实测或代码级验证。

Apache GumpApache Gump2026/10/15

Apache Gump live r1939132 实战与维护状态详解

目标：回答两个问题——「Gump 跑起来之后内部到底发生了什么」（runner/actor 运行链路的代码级剖析与实测日志对照）与「这个项目现在还能不能用」（README 官方口径、SVN 提交频率实测、官方 vmgump 实例当日运行数据实测、六处已确认的 Python 2/3 适配缺陷清单），并给出接入现代 Apache 项目与自建运维的落地建议；本文全部结论在 Ubuntu 22.04/CentOS 8 双环境实测或经源码逐行验证。

先给结论：Gump 可用、但在低频维护状态——源码提交频率实测约为一年数笔（最近一笔 2026-08-31），包装脚本与个别运行器仍带 Python 2 时代缺陷；但官方服务端 vmgump 至今仍在每天 00:00 UTC 准时聚合构建 148 个 Apache 项目（本文实测取到 2026-10-15 当日运行报告，成功率 75.68%）。用它做跨项目兼容性聚合检测依然成立，前提是按本文列出的实测边界绕开坏掉的入口。

一、环境信息

  • 实测快照：Apache Gump live，SVN r1939132（2026-08-31 提交，作者 bodewig）；内部版本串双轨 setting.VERSION='2.3' 与 cron/gump.py GUMP_VERSION='2.0.2-alpha-0003'
  • 实测系统一：Ubuntu 22.04.5 LTS，Python 3.10.12，OpenJDK 11.0.32.1，Ant 1.10.12
  • 实测系统二：CentOS Linux 8，Python 3.6.8，OpenJDK 11.0.13（用于交叉验证兼容性结论）
  • 源码目录：/root/gump（含 svn:externals 检出的官方元数据 72 个项目定义文件）
  • 官方实例观测对象：http://vmgump.apache.org/（实测日期 2026-10-15）
cd /root/gump && svn info | grep Revision && python3 --version

Revision: 1939132
Python 3.10.12

二、维护状态详解

2.1 官方口径（README 原文）

仓库 README 对自身定位的表述（原文照录，实测提取自 /root/gump/README）：

Gump is Apache's continuous integration tool. It is written in python and fully
supports Apache Ant, Apache Maven and other build tools. Gump is unique in that
it builds and compiles software against the latest development versions of
those projects.

README 同时明确了贡献元数据的工作流（编辑 metadata/project/ 下的描述文件，提交前跑 ./gump validate，然后用 svn commit 提交）——这与第 4 篇的校验链实测一一对应。README 没有给出任何「版本发布」的概念，与「live 主干即发布」的形态一致。

2.2 提交频率实测

从 SVN 日志实测最近两笔提交：

cd /root/gump && svn log -l 2 -q

------------------------------------------------------------------------
r1937687 | bodewig | 2026-08-31 20:24:48 +0800 (一, 2026-08-31)
------------------------------------------------------------------------
r1928372 | bodewig | 2025-09-12 23:16:07 +0800 (五, 2025-09-12)
  • 最新提交 r1937687（2026-08-31），上一笔 r1928372（2025-09-12），间隔约 11 个月；
  • 单一维护者（bodewig）近年承担几乎全部提交；
  • 属于典型的低频维护项目：主干可用、无版本发布、缺陷修复以月/年计。

2.3 官方服务端运行实测（2026-10-15 当日）

维护状态的另一面看官方实例：http://vmgump.apache.org/ 首页即是 Gump 生成的运行报告，实测提取的关键数据：

Apache Gump(TM) Run GUID    gump1-ec2-or.apache.org:vmgump:20261015000004
Gump Version                2.3
Start Date/Time (UTC)       Thu, 15 Oct 2026 00:00:05 (UTC)
End Date/Time (UTC)         Thu, 15 Oct 2026 06:24:06 (UTC)
Projects  Successes          Failures      Prereqs    No Works   Packages
148       112 (75.68%)       08 (5.41%)    00 (0.00%) 00 (0.00%) 28 (18.92%)

实测结论：

  • 官方聚合构建至今每天定时运行（当日 00:00:05 UTC 开跑，06:24:06 结束，全程约 6.4 小时），聚合 148 个项目；
  • 当日成功率 75.68%，8 个构建失败，28 个项目因前置问题未执行工作（No Works/Packages）；
  • 这证明「跨项目兼容性探测」这条核心价值链路在官方侧仍是活的，本文自建实验的产出（HTML/RSS 报告）与官方同构。

💡 技术拓展：判断 Gump 这类「元项目」的维护状态，单看仓库会有误判——

观测面实测手段r1939132 实测结论
源码提交svn log -l 2 -q低频（最近间隔 11 个月）
官方运行vmgump 首页 Run GUID/日期每日运行，当日报告可取
官网文档status/results 页文档内容陈旧（案例停留在 2001 年）

本文采用「仓库 + 官方实例」双观测，结论：代码低频维护、服务仍在服役、自建部署可行但需按第 2.4/四节绕开已知缺陷。

2.4 已确认缺陷清单（全部实测或代码级验证）

以下是 r1939132 快照上六处已确认问题，也是低频维护状态的直接体现：

编号位置现象（实测）影响
D1./gump 包装脚本 check_env_pylib生成 print "error" 的临时脚本，Python 3 下必报 SyntaxError./gump run 的库预检失效（报错后主流程仍继续）
D2workspace version 属性DTD 要求大写 VERSION，实现读小写 version；大写写法使 bin/build.py 抛 TypeError: '>=' not supported between instances of 'NoneType' and 'str'元数据须按实现（小写）书写，DTD 校验对 workspace 形同虚设
D3bin/update.py/bin/build.py 独立入口初始化阶段 RuntimeError: Not Implemented on TextResolver: getFile.，py3.10 与 py3.6 复现一致独立更新/构建入口不可用（根因见 3.4 节）
D4gump/actor/rdf/describer.pyfrom rdflib import TYPE 在新版 rdflib 报 ImportErrorRDF 描述器被跳过（有容错，不影响退出码）
D5cron/gump.py 版本检查if not major >= 2 and minor >= 3: 运算优先级错误（先 not 后 and），且异常分支引用不可调用的 sys.version()版本门槛检查形同虚设（实测 py3 通过但并非按原意）
D6官方元数据与 DTD 脱节easymock.xml/junit.xml 两处 validity error（属性未声明、子元素违规）校验基线含噪音，新增元数据只能对比增量

这六处均不需要使用者修复源码——第 3、4 篇已给出全部绕行写法（小写 version、直连 integrate、规避 mvn3install 的未声明属性等）。

三、实战：完整运行链路剖析

3.1 运行器体系：谁在执行 integrate

bin/integrate.py 构造 GumpRun 后交给 gump/core/runner/ 的运行器执行。实测确认两类运行器：

  • DemandRunner（需求驱动）：被 update/build 独立入口使用，python/gump/core/runner/demand.py 调 self.initialize(True) 完成初始化；
  • LinearRunner/集成链路：integrate 与 cron 链路使用，完整跑「环境检查 → 加载 → 更新 → 构建 → 统计 → 文档 → 联合分发」。

命令到阶段的实测映射（第 3 篇日志逐段核对）：

bin/integrate.py → runner.perform()
  ├─ 环境检查（env.py 同款探测：java/javac/svn/git/...）
  ├─ WorkspaceLoader 加载元数据（DTD 合法性由 validate 保证，加载只管对象图）
  ├─ Update（SCM 阶段，实测 git clone/fetch 真实执行）
  ├─ Build（逐项目，按依赖图排序，实测 ant 调用与失败记录）
  ├─ Statistician 统计（stats.db 落盘）
  ├─ Documenter 生成 HTML 日志站
  ├─ Syndicator 生成 RSS/Atom
  └─ Synchronizer 同步 work→logs 并清理

3.2 actor 体系：可选行为的插件链

运行链路的「胶水」是 actor 注册表（runner.py 的 initializeActors，实测通读源码），按固定顺序注册：

TimeKeeper → Statistician → Resulter(多服务器) → Databaser/Historical(official+DB)
→ Dynagumper(有 DB 配置时) → Documenter(Text/XDoc 二选一) → Syndicator(需 isSyndicate)
→ RDFDescriber(需 isDescribe) → RepositoryPublisher → MvnRepositoryProxyController
→ LocalMvnRepositoryCleaner → Synchronizer → Notifier(最后)

实测对照：第 3 篇离线运行的日志尾部出现了 Document run using [XDocDocumenter]、Syndicate run using [...RSSSyndicator...]、[...AtomSyndicator...] 与 Wipe Directory [.../xdocs-work]——与上述链路逐一对应；Unable to register RDF Describer 警告即 D4 缺陷在注册阶段的容错输出。

3.3 状态模型：模块成功、项目可以失败

实测（第 3 篇 commons-io 集成）验证的状态语义：

  • 模块状态只反映 SCM 检出：git clone/fetch 退出码 0 → State: Success；
  • 项目状态反映构建：ant 退出码 1 → State: Failed / Reason: Build Failed；
  • 两级状态各自落盘到 logs/<模块>/<项目>/index.html，聚合首页汇总（官方 vmgump 的 148 项目统计表即同款产物）。

3.4 update/build 崩溃的代码级根因（D3 展开实测）

第 1、2 篇实测的 Not Implemented on TextResolver: getFile 崩溃，本文追到代码级根因，三条证据链：

  1. bin/update.py 第 72 行与 bin/build.py 第 63 行均显式 options.setText(True)——独立入口强制文本模式；而 integrate.py 不设置，options.py 默认 self.text = False 走 XDocDocumenter；
  2. TextDocumenter 的 TextResolver.getFile 未实现（gump/actor/document/text/resolver.py 第 64 行直接 raise RuntimeError('Not Implemented on ' + ...)），XDocResolver 实现了同名方法；
  3. RSS 联合分发器默认注册且在初始化事件中调用 resolver.getFile(...) 生成订阅文件——text 模式下解析器没有该方法，于是崩溃。

结论：这不是 Python 3 特有的语法问题，而是「入口默认组合了一个无实现的解析器路径」的组合缺陷；官方服务端从不单独跑 update/build（cron 一律走 integrate），所以缺陷长期存活。绕行策略维持第 3 篇结论：一切通过 bin/integrate.py。

四、实战：接入现代 Apache 项目的适配建议

4.1 构建器选择：ant 元数据的现实困境

第 3 篇实测：commons-io 主干已无 build.xml（纯 Maven 项目），对它写 <ant> 元数据注定失败。实测给出的适配原则：

  • 现代项目用 <mvn3>：官方元数据里 Maven 项目的主流写法（第 4 篇 mvn3 属性表），Gump 会调用 Maven 并配合 Maven 仓库代理（workspace 的 mvnRepoProxyPort，actor 链里的 MvnRepositoryProxyController 负责起代理）；
  • 预置件用 <mvn3install>：把上游尚未发布的构件装进 Maven 本地仓（注意规避第 4 篇 5.5 节的未声明属性写法）；
  • Ant 项目继续 <ant>：配合 <depend> 让上游 Gump 项目的 jar 注入 classpath（build.sysclasspath=only 由 workspace 统一声明）。

4.2 依赖声明的自检方法

新增项目元数据后的三步实测自检（第 3 篇全部验证过）：

  1. ./gump validate 或自定义工作区跑 validate——无新增 validity error；
  2. WorkspaceLoader 加载自检（第 3 篇 10 行脚本）——项目与依赖边按预期还原；
  3. bin/integrate.py -w <workspace> <项目名> 离线跑一轮——看项目状态与报告页。

4.3 与官方实例对齐的元数据习惯

对比官方 72 个项目定义文件的实测观察：

  • module 与 repository 分离声明，同站点仓库复用同一 repository 定义；
  • <depend> 只声明真实的库依赖，测试框架用 <option>；
  • 每个 <jar> 带 id，下游按构件粒度依赖；
  • 提交前 ./gump validate（README 原文要求）。

五、实战：自建运维建议

5.1 定时运行部署

自建周期聚合的部署形态（按官方链路的最小化复刻）：

  1. 在 workspace 声明项目清单与 basedir/logdir；
  2. 用系统 crontab 定时执行 python3 bin/integrate.py -w <workspace> all（配合 GUMP_WORK_OFFLINE 做干跑/正式两种档位）；
  3. 报告目录（logdir）交给 HTTP 服务器静态托管，RSS/Atom 供订阅方轮询——这是官方 vmgump 的同款形态（实测其首页即静态生成的运行报告）。

./gump run 虽可驱动运行，但如 2.4/D1 所述库预检在 Python 3 下已坏，运维脚本建议直连 bin/integrate.py。

5.2 运行产物与留存

单轮运行的实测产物清单（第 3 篇）：logs/ 下 index.html/context.html/buildLog.html 等约 25 个文件 + 每模块子目录（含 rss.xml/atom.xml）+ stats.db 统计库 + changes_to_<模块>.txt 变更清单。运维要点：按 Run GUID（实测格式 主机:workspace:时间戳）命名留存目录，便于与 RSS 订阅方对账。

5.3 健康监控点

  • 每轮运行后的 logs/index.html：确认 Run GUID 与项目统计表生成；
  • 各项目 Reason 字段：Build Failed 之外出现 Prerequisite Failed 说明依赖图异常；
  • RSS/Atom 文件时间戳：确认 Syndicator 正常产出（text 模式不可用的 D3 缺陷提醒：永远以 xdocs 模式运行）。

六、常见问题（FAQ）

Q1：这个项目还值得投入吗？ 取决于目标。做「跨项目兼容性聚合探测」（尤其是维护一批互相依赖的 Java 库时），Gump 的依赖图调度与失败通知依然独特，官方实例每天仍在产出 148 个项目的真实报告（2.3 节实测）；若只是要一台普通 CI，常规工具更省心。按 2.2/2.3 节的双观测结论：代码低频维护但链路可用。

Q2：Python 3 下哪些命令绝对不能用？ 独立调用的 bin/update.py 与 bin/build.py（D3，崩溃于 TextResolver）；./gump run 的库预检环节报 py2 语法错（D1，但主流程可继续）。等价能力全部由 bin/integrate.py 覆盖。

Q3：官方元数据自带校验错误，说明校验流程坏了吗？ 没有。两处报错是元数据内容与 DTD 脱节（D6），校验流程本身实测可靠——本文自定义元数据的正向/反向测试（第 3 篇 2.2 节）均按预期通过/拦截。

Q4：为什么官方实例报告里 Gump Version 是 2.3 而日志里又出现 2.0.2-alpha-0003？ 双轨版本串（8.5 节、一/环境信息）：HTML 报告读 setting.VERSION='2.3'，cron 运行日志自报 GUMP_VERSION='2.0.2-alpha-0003'，同一份代码的两个内部标识，阅读时以 Run GUID 的日期为准。

Q5：我能给 Gump 提缺陷或元数据吗？ 可以，且这是该项目的常规贡献方式：元数据改动走 metadata/project/ + ./gump validate + svn commit（README 原文）；代码缺陷走官方 Issues（命令帮助原文 For bug reports use JIRA: http://issues.apache.org/）。按 2.2 节实测的维护节奏，合入以月计，需有预期。

Q6：自建部署最低需要什么？ 第 1/2 篇方案 A 即可运行校验与单测；加 JDK/Ant 后可离线 integrate；真实聚合构建再加 SCM 客户端与目标项目构建器（现代项目加 Maven）。全部命令与坑位见前三篇。

七、参考链接

  1. Apache Gump 官方主页：https://gump.apache.org/
  2. 官方运行实例（本文 2.3 节数据来源）：http://vmgump.apache.org/
  3. SVN live 主干与提交历史：https://svn.apache.org/repos/asf/gump/live
  4. 仓库 README（2.1 节官方口径来源）：https://svn.apache.org/repos/asf/gump/live/README
  5. 运行器与 actor 源码（3.x 节剖析对象）：https://svn.apache.org/repos/asf/gump/live/python/gump/core/runner/runner.py
  6. Python Gump 使用文档：https://gump.apache.org/python/usage.html