JDK7升JDK8及Maven3.6.3后执行mvn install报缺失sun-jaxb:jaxb-api:2.2依赖

• 制品文件名与坐标要求不匹配：Maven按坐标sun-jaxb:jaxb-api:jar:2.2查找时，要求目标文件名为jaxb-api-2.2.jar，但你本地.m2对应目录下存的是少了字符b的jax-api.jar，文件名不匹配，Maven无法识别为有效制品。
• 中央仓库无对应坐标制品：sun-jaxb:jaxb-api:2.2是Sun时代早期托管的依赖坐标，随着Sun被收购、官方源迁移，这个特定坐标的制品从未同步到新版Maven默认走的中央仓库路径，Maven 3.6.3对仓库校验的严格度远高于旧版本，不会对缺失制品做模糊匹配。
• 本地自动生成的目录并非有效制品：你删除目录后重新出现的文件，本质是Maven拉取失败时自动创建的占位目录，里面只存了记录拉取失败状态的.lastUpdated标记文件，不存在有效可用的jar包，不是构建过程真的拉取到了目标依赖。
• 多pom分散声明导致依赖路径无法统一仲裁：项目多个pom都独立声明了该旧坐标，没有通过根pom的依赖管理做统一收敛，哪怕单独修改某一个pom的声明，其他路径的原坐标依然会触发缺失校验。

• 修正本地仓库的文件匹配问题：找到本地.m2下repository/sun-jaxb/jaxb-api/2.2目录，把错位的jax-api.jar重命名为符合Maven坐标要求的jaxb-api-2.2.jar，同时删除目录下所有.lastUpdated结尾的拉取失败标记文件，让Maven可以直接识别本地已有制品，跳过远程拉取。
• 替换为中央仓库可正常获取的兼容坐标：把所有pom里声明的sun-jaxb:jaxb-api:2.2统一替换为javax.xml.bind:jaxb-api:2.2，两个包的代码逻辑、API完全一致，只是原Sun托管的制品后来迁移到了JCP维护的javax路径下，不存在兼容性问题，可直接从中央仓库拉取。
• 避免无效重复拉取：可以在项目的pom配置里给中央仓库的更新策略加上限制，对已确认不存在的旧坐标设置<updatePolicy>never</updatePolicy>，避免Maven每次构建都重复拉取不存在的制品、生成无效占位目录。
• 统一依赖仲裁规则：在项目根pom的<dependencyManagement>节点统一声明修正后的jaxb-api坐标，覆盖所有子模块、第三方传递依赖路径里的旧坐标声明，避免分散声明导致的坐标不统一问题。

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