什么是仓库
顾名思义,仓库就是一个进行集中存储东西的地方,放到这里可以理解为集中管理构件(jar包)的地方.仓库包含了绝大多数流行的开源Java构件,以及源码、作者信息、SCM、信息、许可证信息等.
为什么要用仓库
在采用传统方式管理的项目中,通常会把第三方依赖jar包放到./lib
或者./web-inf/lib
下,这种情况会产生如下几个弊端:
- 侵占硬盘空间:虽然现在硬盘的容量已经越来越大,但采用传统方式管理,假设100个项目都用到了log4j,那么硬盘上会存在100个log4j.jar,这种重复对于一个正常的程序猿而言显然是不可容忍的.
- 依赖识别困难:时间久了,往往搞不清楚哪个jar是干嘛的.
- 依赖管理困难:需要人工维护第三方jar依赖的其它三方jar.
版本升级困难:如果想升级版本,除了要浪费时间手动去各jar的官网寻找文件下载,还要搞清楚找到的jar和它所依赖的三方jar版本是否兼容.
然而现在有了仓库,可以对jar进行集中管理,通过书写简单的脚本,可以让构建工具主动去下载对应版本的jar包,并且可以解析所需的三方依赖.从而可以让你从无意义的体力劳动中解放出来.并且采用仓库之后,即便有1W个项目都使用到了同一个版本的log4j,那么所有的项目引用的都是同一个log4j而不会出现存在1W份相同文件的情况.
这里可以理解为如果用传统方式,那么是通过相对路径引用的当前项目某个目录下的依赖,而采用构建工具后,会使用绝对路径引用固定目录下的同一份文件.
仓库的分类
仓库大体可以分为:本地仓库、中央仓库、本地目录点击后面的连接可以查看,关于这几种仓库的使用方式
本地仓库
即本地硬盘存储目录,默认情况下会在系统的用户目录下创建一个.gradle文件夹,所有的依赖都会缓存到此,在依赖检查时,会先检索本地缓存,如果存在那么会直接采用本地缓存目录中存放的依赖,从而节约带宽和时间.
如果想要更改本地缓存目录位置,可以参考Gradle指定/修改缓存目录通过如下几种方式修改,- 法1.通过添加系统变量 GRADLE_USER_HOME
- 法2.设置虚拟机参数 org.gradle.user.home 属性
- 法3.通过命令行-g或者 –gradle-user-home 参数设置
远程仓库
远程仓库又分为以下三种- 中央仓库
最核心的中央仓库,其中包含了绝大多数构件(jar包),一般而言java项目的依赖都可以在这找到,比较常用的有
mavenCenter()
,jcenter()
- 公共仓库
有好多良心的公司搭建了一些公共库可以使用,比如osc的 osc repo - 私有仓库
这里通常指的是公司内部或者个人搭建的私服,可以通过Nexus或者Artifactory,搭建私有服务器,采用这种方式不仅可以有效降低外网带宽,还可以加快构建速度,增强稳定性.并且当诸如 oracle jdbc驱动这种不存在于中央仓库的jar可以上传到私服而不用采用本地目录的方式进行加载.特别是在条件有限的情况下,诸如开发人员连接外网有限制,公司没有提供VPN且自己又没有梯子的情况下,搭建一台配置VPN的私服绝对是居家旅行,码字构建的必需.要知道在天朝很多情况下没有VPN要么很慢,要么连不上.
- 中央仓库
本地目录
gradle可以直接采用本地目录作为仓库加载所需构件,诸如上文提到的想oracle jdbc驱动这种在中央仓库不存在的流氓构件,如果你恰好又没有条件搭建私服的话,可以像传统方式一样放到lib
下直接从本地加载.至于oracle jdbc驱动为何不在中央仓库的问题不在本文讨论范围,欲知详情的,自行搜索
仓库的坐标
仓库中构件(jar包)的坐标是由groupId、artifactId、version
组成的字符串构成的,在仓库中通过以GAV组成的坐标来定位所需的jar包.在gradle中可以通过以下方式来声明依赖:
testCompile group: 'junit', name: 'junit', version: '4.0'
这里前面的testCompile是声明依赖的的方位,如果不理解可以暂时忽略,后面会有章节讲到,当然如果你觉得这种方式太过繁琐,可以省略group、name、version
三个单词,把构件的坐标采用以:
分割的方式简写为如下方式.
testCompile 'junit:junit:4.0'
当然更细粒度的classifier
这里也是支持的,需要你需要可以按如下方式书写
compile group: 'org.gradle.test.classifiers', name: 'service', version: '1.0', classifier: 'jdk14'
或者简写为
compile "org.gradle.test.classifiers:service:1.0:jdk14@jar"