ElasticSearch源码编译时如何选择Gradle版本？

背景

想看看 ElasticSearch 的源码，下载了 ElasticSearch6.3 和 6.8 的版本，用了三个版本的 gradle ，都没有编译成功。

ElasticSearch 和 Gradle 之间的版本对应关系到底如何呢？我从 ElasticSearch 源码包中的说明文档中找到了答案。

确定 gradle 版本

如何确定 ElasticSearch 和 gradle 的版本呢？查看源码文档发现有一个命令。

Before submitting your changes, run the test suite to make sure that
nothing is broken, with: sh ./gradlew check

就敲了一下，找到了版本之间的对应关系。

下载对应版本的 gradle

gradle 的二进制包，直接解压后设置 bin 目录到环境变量就可以了。编译 ElasticSearch6.3 的化，需要 gradle4.5。

进入源码对应目录，执行命令 gradle idea :

编译失败，因为 JDK 版本不一致，重新下载一个 JDK 1.10 后重新编译。

总结

执行 gradle idea 命令时，如果碰到网络不好，解决某些依赖包时会出现请求超时导致编译失败的问题，解决办法就是多执行几次命令就能成功。

JDK 下载的时候，需要注册 Oracle 帐号，而且帐号登陆在 Edge 浏览器下有表单不兼容问题，导致下载操作没反应，所以建议用谷歌浏览器登陆 Oracle 帐号后再下载。

启示录

昨天听了一本书《弹性思维》，我想了一下，找到 gradle 和 ES 版本对应关系的过程，就是大脑弹性思考的结果。原以为网上能找到 ES 源码和 gradle 的对应关系呢，很遗憾，没找到。

而 gradle 和 ES 的版本更替都太快了，下了三个 gradle 一一试还是不行，不是好办法。所以从 ES 源码中的文档入手，发现有一个 DISTISTRIBUTION.md 的文档，找文档中跟 gradle 有关的命令，看到了 gradle check 就试了下，Bingo ，问题解决！

而编译过程中失败时，扫了一眼异常信息是 Readtimeout 之类的网络超时，联想到编译 Tomcat 时 maven 依赖包下载也有失败的时候，就多执行了一次。

最后，想感慨一下，异常信息确实是个好东西，好的日志能让人反应出如何解决问题，所以项目开发中用好日志很重要啊！