Gradle迁移至Maven Central遇阻：无POM文件的Maven构件在JCenter可用却无法解析

我来帮你逐个拆解这些问题，结合Gradle和Maven仓库的运作逻辑来解释：

1. 非常老旧的Maven构件是否必须包含POM文件？ #

并不是必须的。在Maven生态早期（比如Maven 2刚推出的阶段），规范还没有完全统一，很多构件只上传了JAR包，没有对应的POM文件。后来随着Maven和Gradle等构建工具的发展，POM才逐渐成为构件发布的强制要求——它负责定义构件的元信息、依赖关系等核心内容。但那些早年发布的老旧构件，很多确实只有JAR，没有POM。

2. Gradle是如何访问https://jcenter.bintray.com/的？ #

Gradle访问JCenter的逻辑和Maven Central本质一致：都是按照Maven仓库的标准路径格式，先请求构件的POM文件，再根据POM拉取对应的JAR或其他资源。但JCenter当年作为Bintray旗下的仓库，定位是一个更包容的"超级仓库"——它同步了大量第三方仓库的内容，包括一些不符合严格Maven规范的构件，而且对构件的校验规则比Maven Central宽松很多。

3. 有没有办法确认JCenter上的该构件是否存在POM文件？ #

虽然现在JCenter公开访问返回403，但你有两个靠谱的途径：

• 检查本地Gradle缓存：之前用jcenter()成功构建过的话，你的本地Gradle缓存目录（一般在~/.gradle/caches/modules-2/files-2.1/woodstox/wstx-asl/3.2.7/）里会保存当时下载的所有文件，直接查看是否有以.pom结尾的文件即可。
• 使用互联网存档工具：可以通过历史快照类工具查看该构件在JCenter的历史状态，确认当时是否存在POM文件。

4. 如果JCenter上的该构件也没有POM文件，为何Gradle使用jcenter()时能正常构建，而使用mavenCentral()时却失败？ #

核心原因是两个仓库的规范要求和处理逻辑不同：

• Maven Central的严格性：现在的Maven Central完全遵循Maven规范，要求所有构件必须包含合法的POM文件，没有POM的构件会直接被判定为"不存在"，Gradle无法完成依赖解析。
• JCenter的包容机制：JCenter当年允许缺失POM的构件存在，而且Gradle在和JCenter交互时，会有特殊的 fallback 逻辑：当请求POM失败时，它会尝试直接拉取JAR包，并自动生成一个包含基本元信息（groupId、artifactId、version）的默认POM，以此满足依赖解析的要求。另外，JCenter本身也可能为这类缺失POM的构件生成了虚拟POM返回给构建工具，让Gradle可以正常完成构建。

额外的解决建议 #

针对你现在的问题，有几个可行的修复方案：

• 手动指定构件类型：在Gradle依赖中明确指定只拉取JAR包，跳过POM的校验，示例代码：

  dependencies {
      implementation("woodstox:wstx-asl:3.2.7") {
          artifact {
              name = "wstx-asl"
              type = "jar"
              extension = "jar"
          }
      }
  }
  

• 上传自定义POM到私有仓库：如果你的团队有私有Maven仓库，可以自己生成一个包含必要信息的POM文件，和JAR包一起上传，然后在Gradle中配置私有仓库地址。
• 替换为兼容的现代依赖：如果可能的话，尝试升级这个老旧依赖到有完整POM的版本，或者替换为功能类似的现代构件，从根源上避免这类问题。

内容的提问来源于stack exchange，提问作者Jeff C Johnson