junwucs/repox

❗ OSChina仓库于2015年8月4日重开服务，请自行更新Upstreams配置

❗ OpenKaola仓库入口 url 发生了变化，新的入口是 http://nexus.openkoala.org/content/groups/Koala-release

Repox的主要目标是改善sbt解决依赖的速度，但由于它的服务方式与url的格式无关，因此也支持ivy, gradle, maven, leiningen客户端，可以作为nexus/artifactory的替代品来搭建私服。

如果对Repox的背景不感兴趣，希望快速脏手，可立即前往入门指南

每次sbt项目的依赖发生变更，或是sbt版本升级时，sbt会先resolve很长时间，然后download很长时间，甚至有时显示downloading，但你发现事实上没有网络流量产生，sbt假死。
为了对已经下载过的依赖进行缓存，保证后续请求能够快速完成，你安装了nexus，并把所有sbt可能用到的仓库以及国内的代理仓库（如oschina等）都设置为nexus的上游，却发现它对于sbt更新依赖慢的问题并没有什么改善。
你试图安装typesafe官方使用的Artifactory，却发现其开源版本不支持sbt所使用的自定义url格式。

sbt默认所使用的仓库都在国外。
从某一个版本起，sbt默认使用https协议访问仓库。由于众所周知的原因，连往国外的https连接不稳定，而sbt对这种网络连接的不稳定没有相应的发现和重试机制。
sbt对依赖的请求分为四个步骤：
1. resolve : 向所有仓库（内置的如typesafe repo, central maven等，以及build中添加的resolvers）逐个发送HEAD请求询问是否收藏有此文件
2. download : 向收藏了此文件的仓库发送Get请求下载文件
3. resolve checksum : 向上游仓库发送HEAD请求询问是否有此文件的sha1 checksum
4. download checksum : 如果HEAD返回200，则下载 sha1 文件并保证从原文件计算出的sha1与checksum文件的内容一致
如果没有组织内私服，那么只在每个开发者的本地~/.ivy2/cache目录下有依赖缓存，无法在多个开发者之间共享。
如果我们需要源码包（这对使用ide的开发者很正常），sbt连巨大的javadoc包也要一起下载。
各种bug，例如这个

代理所有流量

这样可以在所有环节进行优化。
要么快速完成，要么快速失败
- 如果上游仓库中有请求的文件，尽量选取最快的仓库下载。
- 下载过程中如果发现当前连往上游仓库的网络连接长久没有获得数据，则终止重试。
- 如果所有上游仓库都失败，则向sbt返回404，让用户重试，而不是永久等待。
重要提示：这一条意味着使用repox时，sbt将有更大的概率更新失败，提示“download failed”错误。这时只需要重试失败的指令即可。我们认为多重试几次是比漫长的等待更友好的用户体验。
与url的格式无关

因此除了改善sbt解决依赖的速度，Repox 还可以为ivy, gradle, maven, leiningen客户端服务。
做代理该做的事

对于已经下载过的文件，保证resolve立即成功。

更多的细节请参阅其它Wiki页。

核心代码仅十几个文件，每个文件不超过200行。约一个周末的阅读量。

undertow + akka + async-http-client

Repox是由我们团队自己的需求驱动的，它支持着我们的日常开发任务。

junwucs / repox