Maven仓库空POM/JAR文件致geonetwork-opensource构建失败求助

1. 核对Maven配置文件一致性 #

• 对比新旧机器的settings.xml（路径：C:\Users\<用户名>\.m2\settings.xml或Maven安装目录conf\settings.xml），确认镜像、仓库、私有仓库凭证配置完全一致
• 检查镜像规则是否覆盖了必要仓库的访问，尝试临时注释镜像配置，直接从中央仓库下载测试
• 确认是否存在profile配置差异，导致依赖拉取的仓库源不一致

2. 验证网络与代理状态 #

• 检查新机器的系统代理、Maven代理配置，与旧机器保持一致，必要时关闭代理测试
• 执行mvn clean install -DskipTests -X开启debug日志，查看依赖下载阶段的网络请求细节，定位是否有连接超时、HTTP错误码等问题
• 手动访问依赖的POM/JAR文件URL（比如jaxen的POM地址），确认浏览器能正常下载，排除网络访问限制

3. 排查Windows安全软件干扰 #

• 临时关闭Windows Defender实时保护、防火墙及第三方杀毒软件，重新执行构建
• 查看Windows Defender保护历史，确认是否有Maven下载的文件被拦截隔离
• 将.m2/repository目录添加到安全软件的信任列表中

4. 确认环境配置正确性 #

• 执行java -version和mvn -v，验证当前JDK与Maven版本匹配对应分支要求（4.2.x用JDK8，main用JDK11）
• 检查JAVA_HOME、MAVEN_HOME环境变量，确保无版本冲突或配置错误
• 重新下载安装Maven 3.9.4，排除安装包损坏问题

5. 清理本地仓库并强制重新下载 #

• 手动删除.m2/repository中空文件对应的目录（如jaxen/jaxen/1.1.4），执行mvn dependency:purge-local-repository清理无效依赖
• 执行mvn clean install -DskipTests -U，强制更新所有依赖（包括发布版）

6. 检查Git仓库完整性 #

• 执行git status、git diff对比新旧机器的本地代码，确认无文件缺失或损坏
• 尝试重新克隆官方仓库测试，排除fork仓库的代码问题

7. 排查CPU架构相关兼容性 #

• 尝试添加JVM参数执行构建：mvn clean install -DskipTests -Dmaven.compiler.fork=true，强制fork独立JVM进程编译
• 确认JDK为通用架构版本，或尝试安装AMD针对性优化的JDK版本测试

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