Understand and configure the build.gradle file (basic teaching)

Advantages of gradle

Note: If you want to understand the difference in depth, then go to the bloggers who specifically explain here, they will be more detailed than I said. This article is mainly about the configuration and understanding of the file

Simply and crudely speaking, it
is to simplify our tedious configuration

One of the two main files of gradle is settings.gradle and build.gradle

Here is a quote from Baidu to explain that the settings.gradle
file is optional for single-project builds, but this file is necessary for multi-project builds, because you need to declare which sub-projects need to participate in the build in this file, including sub-project paths, names, etc.
Gradle Multi-project builds are allowed in any sub-project. How does Gradle decide whether the build is a multi-project or a single-project build? If there is a settings.gradle file in the build directory, then it will be built based on that file; if the file does not exist, then the file will be queried to the upper level directory for the existence of the file (note: only the parent directory will be queried, not always Recursive query of the upper-level directory), if it exists, build it based on the file, otherwise the build is a single-project build. Therefore, if you need to build a single project in a project directory structure of a multi-project, we can create a settings.gradle file in the root directory of the target subproject

Ok, so when we are a novice, we may not be able to handle a single project, so we don't want to run.

Build.gradle file structure and its configuration

plugins

// 需要引进的相关插件Plugins
plugins {
    
    
    // 'java' 表示应用java插件添加对java的支持
    id 'java'
    // 'idea' 表示应用idea插件添加对idea的支持
    id 'idea'
    // gradle
    id 'io.franzbecker.gradle-lombok' version '3.1.0'
    // Spring boot
    id 'org.springframework.boot' version '2.1.6.RELEASE'
    // Maven
    id 'io.spring.dependency-management' version '1.0.8.RELEASE'
}

The code comments are very obvious. If you want to build your own project, this configuration can be taken into your project. Of course, you have to consider whether your project needs these plug-ins.

repositories

// repositories闭包  存储库
// 声明在何处查找项目的依赖项
repositories {
    
    
//    指定使用maven本地仓库，而本地仓库在配置maven时setting文件指定的仓库位置。
    mavenLocal()

    maven {
    
    
        name "aliyun"
        url "https://maven.aliyun.com/repository/gradle-plugin"
    }

    // 这是Maven的中央仓库，无需配置，直接声明就可以使用
    mavenCentral()

    // JCenter中央仓库，实际也是是用的maven搭建的，但相比Maven仓库更友好，通过CDN分发，并且支持https访问。
    // jcenter()
}

We must pay attention to distinguish between what is a warehouse and what is a dependency. A
warehouse is used to store dependencies. Dependencies are equivalent to goods and are stored in the warehouse.

dependencies

// dependencies闭包  依赖
// 是用于声明这个项目依赖于哪些jar
dependencies {
    
    
    implementation 'org.springframework.boot:spring-boot-starter-web'

//    implementation 'com.alibaba:druid-spring-boot-starter:1.1.18'

    implementation 'org.mybatis.spring.boot:mybatis-spring-boot-starter:2.1.0'

    implementation 'org.mybatis:mybatis-typehandlers-jsr310:1.0.2'

    implementation 'mysql:mysql-connector-java:5.1.47'

    implementation 'com.github.pagehelper:pagehelper-spring-boot-starter:1.2.12'

    implementation group: 'com.alibaba', name: 'fastjson', version: "1.2.53"

    implementation group: 'commons-io', name: 'commons-io', version: '2.6'

    compileOnly 'log4j:log4j:1.2.17'

    testCompile group: 'junit', name: 'junit', version: '4.12'
}

(Expanded) Explanation of various ways of dependence

The keyword in front of each dependent jar is the dependence mode of the jar

• 
  The feature of the implementation instruction is that for dependencies compiled with this command, projects that depend on this project will not be able to access any program in the dependencies compiled with this command, that is, the dependency is hidden internally and not externally. public.
• api is
  exactly equivalent to compile instruction
• compile
  this is our most common way to use this method relies on libraries will be involved in compiling and packaging.
• testCompile
  testCompile is only valid when the unit test code is compiled and the test apk is finally packaged.
• debugCompile
  debugCompile is only valid when the debug mode is compiled and the final debug apk is packaged.
• releaseCompile
  releaseCompile is only for the compilation of Release mode and the final Release apk packaging
• Provided is
  only valid at compile time and will not participate in packaging. You can use this method to depend on in your own moudle. Such as com.android.support, gson and other libraries commonly used by users to avoid conflicts.
• The apk (runtimeOnly)
  only participates in the packaging when the apk is generated, and does not participate in the compilation, and is rarely used.