Java Gradle Getting Started Guide dependency management (add dependencies, warehouses, version conflicts)

Java Gradle Getting Started Guide dependency management (add dependencies, warehouses, version conflicts)

@gzdaijie
This article is the author original, reproduced please indicate the source: http://www.cnblogs.com/gzdaijie/p/5296624.html

Directory

1. Add a Dependency package name
1.1 Dependency Types
1.2 Declaration dependent
1.3 Adding Java Dependencies
1.4 Finding a dependent package name
1.5 Complete examples
2. Adding a dependent warehouse
3. Dependency FAQs
3.1 Dependency transitivity
3.2 Version Conflicts
3.3 Dynamic Dependencies
3.4 More Settings

Development of any software, how to manage dependencies is a bypass, software development process, we tend to use such a third-party library, this time, a good dependency on management is particularly important. As an automated build, Gradle is well-supported for dependency management.

Usually we use the IDE (Eclipse, Idea, Android Studio) To develop Java projects, the IDE automatically created a gradle file for us, adding a few lines of dependency, but also simple line of code, this essay will gradually explain the Gradle dependency management method, We hope to help you.

1. Add a Dependency package name

Return

1.1 Dependency Types

Common dependencies consist of two types:

• A class is a library that is required in a project, including local/warehouse files and other project files (for example, a multi-project project, one project depending on another project)
• A class of libraries that are required to automate compilation, deployment, and so on, including Gradle APIs and groovy-authored tasks, plugin, and so on, which are mentioned and used in the first 2 essays

1.2 Declaration dependent

The declaration relies on using the following closures

Dependencies {    // dependencies}

1.3 Adding Java Dependencies

Here, we build Java projects as an example, to build a Java project first need to apply Java plug-in, plug-in use can refer to the previous essay Java Gradle plug-in management

Java plug-in for different operations, the dependency is divided into 10 classes (see Java plugin 45.5), the following describes the common 5 classes

1. Compile: Source code (SRC/MAIN/JAVA) compile-time dependency, most commonly used
2. Runtime: Source code (Src/main/java) dependent upon execution
3. Testcompile: Test code (src/main/test) dependency at compile time
4. Testruntime: Dependency of Test Code (SRC/MAIN/JAVA) execution
5. Archives: Dependencies when Project packaging (E.g.jar)

Typically, a jar dependency needs to include the JAR filegroup (group/namespace), the jar file name (name), the jar version (versions), and, in special cases, the JDK version. Adding a dependency can be in the following ways:

/*Single Dependency*/Compile group:' log4j ', Name: ' log4j ', version: ' 1.2.17 '//abbreviation = Compile ' log4j:log4j:1.2.17 ' /*add multiple dependencies as an array*/Compile' joda-time:joda-time:2.9.2 ', ' log4j:log4j:1.2.17 '/*closure form to add additional configuration*/Compile (group:' log4j ', Name: ' log4j ', version: ' 1.2.17 '){    // ... Additional Configuration}/*equivalent to*/Compile (' log4j:log4j:1.2.17 '){    // ... Additional Configuration}

View Code1.4 Finding a dependent package name

Click Maven website

1.5 Complete examples

// sourcecompatibility = 1.8 is a Java version and defaults to the current JVM version of apply plugin:' java' = 1.8 = ' 1.0 '  repositories {    mavencentral ()} dependencies {    ' org.springframework:spring-context:4.2.1.release '      ' log4j:log4j:1.2.17 '}

View Code

• Repositories{.} is the warehouse where these packages are placed, and the following describes
• Sourcecompatibility, version is just some of the Java plugin properties, see Java plugin 45.8

2. Adding a dependent warehouse

Return

You may wonder where these dependencies are found, and where they have been declared. Repositories defines a repository for download dependencies

/**/repositories {    mavencentral ()}/** / repositories {    jcenter ()}/* */*/*  Local repository is a previously downloaded dependency, cached on Local disk  */repositories {    mavenlocal ()}

View Code

• No need to remember the address of the warehouse, directly use, multiple warehouses can be used at the same time, usually we will use the remote warehouse with the local warehouse, because the cache of files on the local disk faster, do not need to repeat the download.
• About the difference between Jcenter and mavencentral, recommended to see StackOverflow's answer
• Of course, foreign warehouses in the domestic use of the speed may be slow, gradle support custom address, such as the company's warehouse address, domestic warehouse mirror address.

repositories {mavenlocal ()/*Specify the local warehouse address*/maven {URL"File://E:/githubrepo/releases" }    /*the specified remote warehouse*/maven {URL"http://mvnrepository.com/" }    /** Company warehouse, may need to verify * not recommended to write the user name password directly in Build.gradle * can be written in ~/.gradle/gradle.properties, and then use*/maven {URL"<you_company_resp_url>"Credentials {Username' Your_username 'Password' Your_password '        }    }    //Support Ivy WarehouseIvy {url ' <ivy_resp_url> ' }}

View Code

Sometimes we need to invoke our own compiled implementation of *.jar, we can also map the folder containing these files (different from mavenlocal) to a warehouse, but it is generally not recommended

Repositories {    Flatdir {  ' libs1/java/... ', ' LIBS2 '} }

View Code3. Dependency FAQs

Return

3.1 Dependency transitivity

Many libraries rely on other libraries, such as A.jar dependent B.jar, in Gradle, just add A.jar, and Gradle will automatically download all the libraries a relies on.

But sometimes you don't want gradle to do it automatically, like you want to know clearly which libraries to add, configure the transitive implementation, compile the times wrong, and you'll know what additional libraries you need to add.

Dependencies {    //  transitive property defaults to True    compile group: ' log4j ', Name: ' log4j ', Version: ' 1.2.17 ', transitive:false}

View Code

Another scenario is that relying on delivery can cause version conflicts, that is, libraries that rely on pass-through downloads may conflict with another version of the library that the project relies on, in which case some libraries can be excluded and all other dependent libraries, which are selective exclusions, are downloaded.

Dependencies {    compile (' commons-httpclient:commons-httpclient:3.1 ') {        Exclude group: // exclude the dependency        of the group // exclude group: ' Commons-codec ', module: ' Commons-codec '         // Group is a required option, module optional     }}

View Code3.2 Version Conflicts

Version conflicts are very common, such as the following example

// Library A transitive dependent library b-1.2, conflicts with added b-1.1 Dependencies {    ' a:a:1.0 '    b:b:1.1 '}

View Code

Gradle There are several ways to resolve conflicts:

• Recent version policy (default): The previous example ignores b-1.1 and downloads b-1.2
• Conflict Failure Policy: compilation fails when a conflict occurs (some newer versions of the library are not compatible, so the library allows developers to make the choice voluntarily)
• Force specified version policy: When a conflict occurs, use the version specified by the developer

/* Conflict failure policy settings */ Configurations.all {    resolutionstrategy {  failonversionconflict ()}//*  Force specified version policy setting  */Dependencies {    Compile group:' B ', name: ' B ', version: ' 1.1 ', Force:true  }

View Code3.3 Dynamic Dependencies

Dynamic dependency increases the flexibility of library version dependencies

Dependencies {    /*  Select more than 1 versions, which makes the odds of a version conflict smaller *    /compile group: ' B ', name: ' B ', version: ' 1.+ '/    **/    compile group:' A ', Name: ' A ', Version: ' Latest.integration '}

View Code3.4 More Settings

Specifying library file types

// ext default jar, optional attribute is war, zipcompile group: ' B ', name: ' B ', version: ' 1.1 ', ext: ' War '

Using classifiers (classifiers)

// For example, 2 packages are available, A-1.0-dev.war, A-1.0-dev.jarcompile group: ' B ', name: ' B ', version: ' 1.1 ', classifier: ' Dev ', ext: ' War ‘

Replace a delivery dependent version

Compile group: ' A ', Name: ' A ', version: ' l.0 ' {    ' b:b:1.1 '}

Common commands

(1) View all dependent libraries Gradle dependencies (21.3-configuration <configuration >-configuration compile =-configuration runtime = view runtime dependencies

View Code

Java Gradle Getting Started Guide dependency management (add dependencies, warehouses, version conflicts)