最近重新学习java，第一步是搞定编译工具，便于后面项目的快速上手，于是简单调研了一下构建工具。
在08年的时候，maven2还比较盛行，但是更多的是ant，因此心里很是怀念ant的时代。没想到一调查，发现ant已经基本上退出了竞争行列，很少项目直接使用ant来build项目了，更多的是使用maven3，以及一个新星：gradle。由于对maven之前掌握就不是很好，大概知道它基于契约，可以做包管理，可以有集中仓库，但是对它一堆的xml的配置深恶痛绝，于是从来没有仔细学会过maven。
看了一下gradle，语法相对简洁，使用groovy来编写的，构建过程也比maven貌似要快一些，尤其在intelj idea中的集成也比较给力。于是就准备认证学习一下gradle，并尝试推广在公司内部使用，看能否代替现在的Maven。
遇到一个问题，maven有强大的包管理工具，gradle更多只是一个构建工具，本身并不提供包管理功能。但是gradle比较强大，支持maven的库，可以在build.gradle中设置使用maven的仓库来实现包管理。
使用maven仓库
在gradle的编译配置文件中，可以使用如下语法定义使用maven库：
repositories
{
mavenLocal()
mavenCentral()
maven
{
url 'http://mvn.xxx:8081/nexus/content/groups/public'
}
}
这里面有几种选择：
- mavenLocal : 只能使用本地的仓库，默认到~/.m2/repository/ 进行寻址，如果找不到则提示无法找到对应的包和库
- mavenCentral：中央库，默认寻找~/.m2/repository 来寻找包文件，如果找不到就发起请求向中央服务器获取包文件，按照gradle官方说明，应该是从~/.m2/settings.xml中获取中央库url，但是实际测试的时候发现，貌似忽略了~/.m2/settings.xml，而是直接使用了 http://repo1.maven.org/maven2/ 这个中央仓库，就会导致下载速度非常慢；
- maven{url xxx} 这种方式可以让gradle在下载包的时候使用指定的本地中央服务器来进行下载
这三者的顺序最好是：
local maven{local server} mavenCentral
这样按顺序寻址，先在本地文件系统查找，如果找不到就到本地server查找，然后再去外部server进行下载。
关于mavenCentral的配置，按道理来将会根据settings.xml寻址，但是我修改了我能够改动的所有settings.xml，都未能如意，并设置了maven_home变量，仍然无效。看来需要stackoverflow问问了。
Gradle编译依赖
Gradle在库包依赖环节中设置的比较灵活，可以依赖于group，单个包，大体上都是：group，包名，版本号
大体定义语法如下：
dependencies {
compile group: 'foo', name: 'foo', version: '0.1'
}
可以简化如下：
dependencies {
compile 'foo:foo:0.1','foo:foo2:0.1',
}
Gradle有几种依赖的定义：
- runtime：运行的时候依赖的包
- compile：编译的时候依赖的包
- testRuntime：运行测试用例需要的包
- testCompile：编译测试代码需要的包
- default：默认需要的包
- archives：打包的时候需要打入的一些包
吐槽
这些语法相对maven来讲还是容易了很多。但是无论怎样，要查找依赖的库的版本，包名总是一件很痛苦的事情。在很早以前，没有包集中管理的时候，都是直接到官方网站去下载，存放在本地的目录里面，增加到classpath中，让开发和编译的时候都很容易通过。由于有了，集中管理，不再去官方网站下载，但是库里面有多少包，版本是什么样的都很麻烦才知道。
幸好，在eclipse里面相对容易查找版本文件，也有人闲极无聊，写了一个findmaven.net，可以根据类名查找你的包，并提供版本名称，方便查看代码的同时可以很容易cp到gradle和maven的配置文件中来。
懒人改变世界，此言不虚。
| 印象笔记，你的工作空间。下载印象笔记 |
