Jakarta EE BOM：为何SOAP相关依赖8版被移除、9版重新加入？

先校准对Jakarta EE BOM的认知 #

Jakarta EE BOM的覆盖范围是动态调整的，很多刚做迁移的开发者会默认BOM是静态的、封装全部历史Java EE API的全量清单，实际并非如此：BOM只会纳入当时已经完成IP合规交接、正式进入Jakarta EE官方治理体系、发布了正式版本的API制品，没有走完这套流程的组件，哪怕历史上属于Java EE的核心能力，也不会被纳入对应版本的BOM管控清单。

Jakarta EE 8版本BOM未包含JAX-WS API的原因 #

• Jakarta EE 8是Java EE正式捐赠给Eclipse基金会后的第一个过渡性版本，核心目标是最小化技术改动、完全兼容原javax.*命名空间下的API，尽可能降低从Java EE 7/8迁移到Jakarta生态的适配成本。
• 当时JAX-WS、JAXB等几个和SOAP Web服务相关的API，因为原归属方Oracle持有的版权、商标合规问题，在Jakarta EE 8的发布时间窗口内，没有完成全量IP转移与Eclipse基金会要求的许可协议转换，不满足成为正式Jakarta API的准入要求，因此没有被纳入当时版本的BOM范围。这个调整完全是流程合规层面的决策，不代表官方计划将SOAP类API移出Jakarta EE的能力规划。
• 这个阶段遇到依赖缺口的开发者，大多都是手动在项目pom里显式声明对应版本的javax:jaxws-api依赖补全配置，因为组件本身的技术逻辑没有变化，只是合规流程未走完，手动引入的依赖是可以和当时的生态完全兼容正常运行的。

Jakarta EE 9版本BOM重新纳入JAX-WS API的原因 #

• Jakarta EE 9是Jakarta生态完成命名空间迁移的关键大版本，核心工作是将所有纳入治理的API从javax.*命名切换为jakarta.*命名。
• 在这个大版本的筹备周期里，Eclipse基金会完成了所有遗留合规问题API的全量IP梳理与交接：将JAX-WS、JAXB等组件的版权、规格所有权全部合规转移到基金会名下，完成了许可协议适配，同时按照jakarta.*的命名规则发布了对应版本的API制品。这些组件正式通过审核进入Jakarta EE核心API目录后，自然就被纳入了该版本BOM的管控范围。

相关公开说明的查阅提示 #

这些调整的记录没有被单独整理成一篇针对JAX-WS调整原因的专题说明，都分散在不同板块的官方项目文档中，因此常规关键词搜索很难直接定位到对应内容：

• 各版本BOM的变更日志会逐版本列明对应周期内纳入、移除的组件清单
• 每个大版本的官方发布说明里，会专门标注当版的API覆盖范围，以及延后纳入组件的具体原因

内容的提问来源于stack exchange，提问作者user4011408