Gradle系列——gradle入门

最新推荐文章于 2024-07-22 10:40:28 发布

ddssingsong

最新推荐文章于 2024-07-22 10:40:28 发布

阅读量200

点赞数

分类专栏： gradle 文章标签： gradle

本文链接：https://blog.csdn.net/u011077027/article/details/103157570

版权

gradle 专栏收录该内容

5 篇文章 0 订阅

订阅专栏

文章目录

1. 为何使用Gradle

工欲善其事必先利其器，我们想要更高率的项目开发，就需要更方便的项目编译构建工具。我们使用eclipse的时候使用的是ant，后来又来了个maven, Maven 又凭借其强大的依赖配置战胜 Ant，基本上成为了 Java 构建的标准；

Gradle 是基于 Groovy 语言的构建工具，它使用易懂的 DSL 语法，将开发过程中需要的编译、构建、测试、打包以及部署工作，变得非常简单方便和重复使用，而且 Gradle 还可以根据需要定义自己的 model。

依赖管理

在软件开发的过程中，我们通常需要使用很多的第三方库，这时一个好的依赖管理工具就显得尤为重要了，Gradle 作为自动构建工具，它对依赖管理支持地非常地好。

依赖类型：第一类是项目中所需要的库，它包括本地或仓库中的文件和其他项目中的文件；第二类是实现自动化编译、部署等所需的库，包含 Gradle 的 API 和 Groovy 编写的 Task、Plugin 等。
依赖范围：控制哪些依赖在哪些 classpath 中可用，哪些依赖包含在一个应用中。常用依赖范围如下：

compile：源代码（ src/main/java ）编译时的依赖，最常用

runtime：源代码（ src/main/java ）执行时依赖

testCompile：测试代码（ src/main/test ）编译时的依赖

testRuntime：测试代码（ src/main/java ）执行时的依赖

archives：项目打包（ e.g.jar ）时的依赖

依赖仓库：使用repositories定义依赖仓库，也可以同时指定多个仓库，还能指定私服仓库。如下代码示例：

/* 指定Maven Central仓库 */
repositories {
    mavenCentral()
}
/* 指定Maven JCenter仓库 */
repositories {
    jcenter()
}
/* 指定Maven本地仓库 */
repositories {
    mavenLocal() 
}

repositories {
    /* 指定本地仓库地址 */
    maven { url "file://D:/local_repository/" }
    /* 指定的远程仓库 */
    maven { url "http://mvnrepository.com/" }
    /* 私服仓库 */
    maven {
        url "<you_company_resp_url>"
        credentials {
            username 'your_username'
            password 'your_password'
        }
    }
}

依赖传递：很多库都会依赖于其他的库，例如 spring-core.jar 依赖 log4j.jar，我们只需添加 spring-core.jar 即可，Gradle 将自动把 spring-core.jar 所依赖的所有库都全部下载下来。
依赖冲突：依赖传递可能会导致版本冲突，即依赖传递下载的库可能与项目依赖的另一个库版本冲突，这种情况下可以排除一些库，而下载其他所有的依赖库，即选择性排除。如下代码示例：
```
compile ("com.alibaba:dubbo:2.8.4") {
    // group是必选项，module可选
   exclude group:'org.springframework', module: 'spring-aop'
}
```
Gradle 解决冲突有以下几种方式：
1. 最近版本策略（默认）
2. 冲突失败策略
3. 强制指定版本策略
动态依赖：动态依赖增加了库版本依赖时的灵活性，如下代码所示：

dependencies {
    /* 选择18以上任意一个版本 */
    compile group:'com.google.guava',name:'guava',version:'18.+'
    /* 选择最新的版本，避免直接指定版本号 */
    compile group:'commons-io',name:'commons-io',version:'latest.integration'
}

2. 强大的任务功能

在 Gradle 的世界中最重要的两个概念就是：工程（ Project ）和任务（ Task ）。每一个工程又由一个或多个任务组成，一个任务代表了一个工作的最小单元，它可以是一次类的编译、打一个 JAR 包、生成一份 Javadoc 或者是向仓库中提交一次版本发布。

而 Gradle 可以创建更为强大复杂的任务，这些任务可以有它们自己的属性和方法，这一点正是和 Ant targets 不一样的地方，这些强大的任务既可以由你自己创建也可以使用 Gradle 内建好的。关于 Gradle 任务的内容，将在第4节中详细分析。

3. 灵活的代码结构

为了更好的组织管理我们的 Gradle 代码，Gradle 提供了很多方法来组织我们的逻辑代码。首先你可以把所有的代码都放在一个任务中实现，但是如果有很多的任务都使用相同的逻辑，那么你可以把这相同的逻辑放到一个方法中，每个任务都共享该方法。如果我们是多工程的话，可以把相同的逻辑封装到一个方法中，这个方法在父级工程中定义，所有子级工程都能共享。如果你的逻辑和属性很复杂，你可以把它们定义为插件形式提供使用。关于 Gradle 逻辑代码封装，将在第6节中介绍。

4. 丰富的插件选择

插件是对 Gradle 功能的扩展，Gradle 有着丰富的插件，例如编译 Java 代码的 java 插件，它添加了新任务（例如 JavaCompile ），域对象（例如 SourceSet ），约定（例如 Java 源代码是位于 src/main/java ），以及扩展的核心对象和其他插件的对象。将在第9节中介绍 Gradle 中常用的插件。

5.易于扩展的自定义插件

Gradle 插件功能可以很好的组织我们的编译逻辑代码，使它能在不同的项目和工程中重复使用。我们可以自定义实现自己的 Gradle 插件，然后分享给其他人使用。我们可以使用不同的语言来实现，不过我喜欢使用 Groovy 来实现的，大家也可以使用像 java、scala 等喜欢的别的语言来实现。关于 Gradle 自定义插件，将在第5节中具体介绍。

6. Gradle 和 Ant 以及 Maven 的关系

1. Ant

Ant 是2000年发布，它是用 XML 作为脚本编写格式，它的学习成本很低不需要什么特殊的准备就能上手，它基于过程式编程的，逐渐具备了支持插件的功能，因此在很短时间内成为了 Java 项目上最流行的构建工具。

Ant 的不足是因为 XML 本质上是层次化的，并不能很好地贴合 Ant 过程化编程的初衷，它的另一个问题是，稍微大型的项目编写的 XML 文件很快就大得无法管理。

2. Maven

Maven 发布于2004年，目的是解决使用 Ant 所带来的一些问题。不过它仍旧使用 XML 作为编写构建配置的文件格式，但是文件结构却有巨大的变化。Ant 需要将执行 task 所需的全部命令都一一列出，然而 Maven 依靠约定（ convention ）并提供现成的可调用的目标（ goal ）来执行构建。而 Maven 最重要的一个功能是，它具备从网络上自动下载依赖库的能力（ Ant后来通过 Ivy 也具备了这个功能），这一点革命性地改变了我们开发软件的方式。

Maven 也有它的问题，依赖管理不能很好地处理相同库文件不同版本之间的冲突，XML 作为配置文件的格式有严格的结构层次和标准，定制化目标（ goal ）很困难。因为 Maven 主要聚焦于依赖管理，实际上用 Maven 很难写出复杂、定制化的构建脚本，甚至还不如 Ant。