Bintray停服后使用mfglabs、commons-aws-sqs、dwhjames库的解决方案

优先匹配公开托管源的可用版本，该方案无需修改业务代码，适配成本最低、风险最小：

• 绝大多数原托管于Bintray的Scala/Java类库已经迁移至Maven Central、Sonatype OSSRH，国内阿里云Maven镜像也同步了大部分常用类库，首先修改你的构建配置（sbt项目修改build.sbt中的resolvers配置，移除Bintray相关源，保留Maven Central即可），尝试直接拉取原版本依赖测试。
• 你用到的三个类库中，mfglabs系列、commons-aws-sqs、dwhjames的常用版本基本都已同步至上述公开仓库，大多情况下仅调整源配置即可解决问题。

如果公开仓库找不到你使用的特定版本，可按优先级选择以下方案：

私有仓库托管原有包 #

• 如果你本地开发环境、同事的设备或者之前的构建缓存中存在对应版本的jar包，可直接将jar包上传至团队内部的私有Maven/Ivy仓库（比如Nexus、Artifactory），再在构建配置中添加私有仓库地址即可，完全不需要调整业务代码和依赖版本。
• 临时应急也可以在sbt项目根目录新建lib文件夹，将对应jar包放入该目录，sbt会自动识别该目录下的依赖，无需额外配置源。

替换为同类维护中的类库 #

如果找不到原有jar包的备份，可以选择功能一致的主流替代类库，长期维护性更好：

• mfglabs的相关能力可以用Circe、Play JSON等主流Scala生态库替换
• commons-aws-sqs的能力可以直接用AWS官方提供的Scala/Java版SDK的SQS模块替换
• dwhjames的AWS相关封装能力也可以用官方AWS SDK直接替代，功能覆盖度更高。

自行编译原库托管 #

如果原库是开源项目，你可以找到原库的公开代码仓库，拉取对应版本的代码自行编译，将编译出的jar包托管到私有仓库即可，也可以根据业务需求后续自行维护迭代。

• 不要使用未经验证的第三方公共镜像站提供的类库，避免引入恶意代码风险
• 如果选择替换类库的方案，需要做好完整的单元测试、集成测试，避免出现兼容性问题

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