删除已关联JCenter的JFrog Bintray包后重新关联的问题求助

首先得说，你遇到的这个问题其实是Maven仓库生态里的一个常见坑——已发布的版本号应该是不可修改的，这是行业通用的规范，也是JCenter这类仓库的默认规则。

为什么会出现依赖找不到的错误？ #

当你第一次把1.0.0版本关联到JCenter后，JCenter会同步这个版本的所有文件到它的服务器上。之后你删除了自己Artifactory里的1.0.0并重新上传同版本号的修复包，JCenter并不会自动重新同步这个版本——因为它认为同一个版本号的内容是固定的，不会去检测你私有仓库里的变更。之前同步的版本已经被移除（因为你删除了原版本），而新的修复包又没被同步到JCenter，所以就出现了依赖找不到的情况。

解决方案分两种情况： #

方案1：遵循规范，升级版本号（强烈推荐）

这是最稳妥也最符合行业标准的做法：

• 不要复用1.0.0这个版本号，直接发布一个新的小版本，比如1.0.1，把修复后的库上传到你的Artifactory。
• 重新在Bintray上申请关联这个新版本到JCenter（如果你的仓库已经关联过JCenter，新版本上传后通常会自动触发同步，不过可能需要等待片刻）。
• 之后在项目里改用compile 'com.mmrx.pngcompress:pngcompress:1.0.1'来依赖，同时执行gradlew clean build --refresh-dependencies（Windows）或./gradlew clean build --refresh-dependencies（Mac/Linux）清理Gradle缓存，确保拉取到新的版本。

这个方法能彻底避免缓存和同步问题，也让你的用户能明确知道使用的是修复后的版本，不会产生混淆。

方案2：强制同步已删除重传的同版本（不推荐，但可尝试）

如果你一定要保留1.0.0这个版本号，可以试试以下步骤：

1. 确认你的Artifactory里已经正确上传了修复后的1.0.0版本，包含pom、jar等所有必要文件，没有缺失。
2. 前往Bintray的支持页面提交工单，说明你的情况：你之前删除了已关联到JCenter的1.0.0版本，现在重新上传了修复后的同版本，请求JCenter团队手动重新同步这个版本。需要提供你的仓库地址和版本号信息。
3. 等待JCenter团队处理同步请求，这个过程可能需要几个小时到几天不等。
4. 同步完成后，清理本地Gradle缓存（执行上面的刷新依赖命令），再尝试依赖。

总结 #

长远来看，一定要遵守版本号不可变的规则，遇到bug就升级小版本号，这能帮你避免很多类似的仓库同步和依赖问题。

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