Tech and Media Labs
This site uses cookies to improve the user experience.




Gradle Dependency Management

Jakob Jenkov
Last update: 2015-08-10

The term Gradle dependency management refers to how Gradle handles the dependencies of your project. A dependency is an external JAR file that your project needs in order to be compiled and executed. For instance, if your project is a Java app that stores data in a database, then your project might use Hibernate to make this task easier. Your project then depends on Hibernate.

Note that project dependencies are not the same as task dependencies. A task may depend on another task. This means that one tasks needs another task to be executed before the task itself can be executed. This has nothing to do with the external JAR file dependencies of your project. These are two different types of dependencies, and Gradle handles them separately.

Maven Repositories

Maven was the first build tool to popularize the idea of central repositories of JAR files from which we could all download the JAR files we need. Inside a Maven build script you can then define what projects (JAR files) your project depends on, and Maven will automatically download the correct JAR files for you.

Gradle is capable of using Maven repositories. Why reinvent the wheel when Maven repositories already work well? Actually, Gradle can also use Ivy repositories. Ivy is a dependency management tool for use with the Ant build tool, since Ant does not have built-in dependency management.

To get Gradle to use the official, central Maven repository you must specify so in the Gradle build script. Here is how that looks:

repositories {
    mavenCentral()
}

Insert this code into your Gradle build script towards the top of the build script.

You can also use your own Maven repository. Some organizations may keep an internal Maven repository which only contains the JAR files which the organization has approved for use in their software (for legal or stability reasons). If you are using your own Maven repository you can specify that inside the repositories block like this:

maven {
    url "http://mavenrepo.jenkov.com/"
}

If you are using two or more repositories you can specify them after each other like this:

repositories {
    mavenCentral()

    maven {
       url "http://mavenrepo.jenkov.com/"
    }
}

This example configures Gradle to use both the central Maven repository and my own Maven repository.

Local Repository

Using your own Maven repository is not the same as using your local Maven repository. The local Maven repository is where Maven stores all JAR files it has downloaded from other Maven repositories, so that it does not have to download them from the remote repositories every time the project is built.

You can tell Gradle to use your local Maven repository by putting the path to your local Maven repository inside the url string in the Maven repository declaration like this:

maven {
    url "C:\\maven\\repository"
}

This example specifies that your local Maven repository is located on the C drive in the mave\\repository folder (a Windows path - in Unix it could have been something like /mydata/maven/repository ).

Declaring Dependencies

In a Maven repository a JAR file is identified by its group name (e.g. the organization that made it), its artifact name (the name of the project / software / tool / API), and a version number (e.g. 1.4.5). When you specify a dependency for your project, the identification of the dependency must contain these three parts.

Dependencies that are compiled outside of Gradle (e.g. downloaded from the central Maven repository) are called external dependencies.

Dependencies are specified inside the dependencies block of your build script. Here is how an empty Gradle dependencies block looks:

dependencies {
}

Insert the dependencies block after the repositories block.

Here is an example dependency declaration inside the dependencies block:

dependencies {
    compile group: 'log4j'  , name: 'log4j'  , version: '1.2.17'
}

This example declares a dependency on Log4J using the group name log4j, the artifact name log4j and the version 1.2.17 .

When Gradle sees this dependency declaration Gradle will try to download it from the central Maven repository.

Dependency Shortcut Notation

There is a dependency shortcut notation using which you can specify the group name, artifact name and version in a single string separated by colons. The dependency declaration example from the previous section could also be declared like this using the shortcut notation:

dependencies {
    compile  'log4j:log4j:1.2.17'
}

Dependency Configurations

If you examine the previous dependency declaration example closely you will notice the word compile in the beginning of the declaration (first line inside the dependencies block). The word compile specifies what dependency configuration the declaration belongs to.

A dependency configuration is group of dependencies used for a specific purpose by your project. For instance, some JAR files might only be needed when you compile your code (like an annotation pre-processor). Other JAR files might be needed when you run the project code, or when you run the unit tests for your project.

The Java plugin provides a few pre-defined dependency configurations that can be useful for you. These dependency configurations are:

  • compile
  • runtime
  • testCompile
  • testRuntime

The compile dependency configuration should contain all dependencies needed to compile the Java code in your project.

The runtime dependency configuration should contain all the dependencies needed to run the Java code in your Project. Most often the JAR files needed at runtime are also needed at compile time, but not always. For instance, a JDBC driver may not be seen by the Java compiler, but will still be needed at runtime. By default the runtime dependency configuration also includes all dependencies in the compile group.

The testCompile dependency configuration should contain all the dependencies needed to compile the unit tests for your project. By default the testCompile dependency configuration also includes the compiled classes and the dependencies from the compile dependency configuration.

The testRuntime dependency configuration should contain all the dependencies needed to run the unit tests for your project. By default the testRuntime dependency configuration also includes all dependencies from the compile, runtime and testCompile dependency configurations.

You can declare multiple dependencies by insert multiple dependency declarations like this:

dependencies {
    compile 'log4j:log4j:1.2.17'
    compile 'jdom:jdom:1.0'

    testCompile 'junit:junit:4.11'
}

Jakob Jenkov




Copyright  Jenkov Aps
Close TOC