Gradle series 11-dependency management

Almost all JVM-based software projects require external class libraries to reuse existing function codes. Automated dependency management can specify the version that is dependent on, and can solve the problem of version conflicts caused by transitive dependencies.

Dependency management key points

1. Working coordinates (jar package logo)

group: indicates the group where the jar package is located
name: indicates the name of the jar package
version: specifies the version of the jar package

Specify the dependent jar package in dependencies:

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

2. Warehouse (storage location of jar package)

Public warehouse (central warehouse): mavenCentral / jecenter
Gradle does not have its own central warehouse, can be configured to use Maven's central warehouse mavenCenter / jcenter

repositories {
    mavenCentral()
    jcenter()
}

Private warehouse: mavenLocal
configuration to obtain dependent jar packages from the local maven warehouse, do not remotely load jar packages, use mavenLocal, you need a local maven environment

repositories {
    mavenLocal()
}

Custom maven warehouse
Custom warehouse source, generally pointing to the company's Maven private server (general practice)

repositories {
    maven{
        url "私服地址"
    }
}

File warehouse (rarely used)
The file path on the local machine, generally not used, does not make much sense, because the purpose of the build tool is to remove the influence of the machine, you can share a warehouse data anywhere, and the machine is associated It does n’t make much sense to go on, except in special cases

Configure the execution order of multiple warehouses

repositories {
    mavenCentral()
    mavenLocal()
    maven {
        url "私服地址"
    }
}

When configuring multiple warehouses, search according to the success of the configuration, return if found, and continue to look down. For example, in the above code, the mavenCentral warehouse will be found first. Until found

Transitive dependence

For example: A depends on B. If C depends on A, then C depends on B
because of the transitivity of dependencies, so the conflict of versions will occur. The following is a picture to understand Gradle's automated dependency management process

gradle tool according to * .gradle The configuration file downloads the required jar package from the remote warehouse and saves it in the local warehouse. If the same jar package is used frequently, it will be stored in the dependency cache

Dependency phase configuration Configure
dependencies in dependencies in build.gradle

1. Source code dependencies:
   compile: configure dependent jars, test code compilation and running, and source code running must exist
   runtime: configure dependent jars, only source code runs and test runs exist
2. Test dependencies:
   testCompile: configure dependent jars, test code compiles and runs
   testRuntime: configure dependent jars, only test code runs

The selection basis of the above four configurations: whether it is only required for the operation phase or whether it is only required for the test phase

Actual combat-logback dependency reference

Go to the Maven repository to find logback:
the address of logback in the maven warehouse
. Introduce dependencies in build.gradle:

dependencies {
    testCompile group: 'junit', name: 'junit', version: '4.12'
    testCompile group: 'ch.qos.logback', name: 'logback-classic', version: '1.2.3'
}

After the introduction is complete, you can see the dependent jar packages from gradle:

after introduction, you can use logback in the test code, the test code is not posted here