Chapter 7. Dependency Management Basics, dependencybasics

Chapter 7. Dependency Management Basics, dependencybasics

This chapter introduces some of the basics of dependency management in Gradle.

7.1. What is dependency management?

Very roughly, dependency management is made up of two pieces. firstly, Gradle needs to know about the things that your project needs to build or run, in order to find them. we call these incoming filesDependenciesOf the project. Secondly, Gradle needs to build and upload the things that your project produces. We call these outgoing filesPublicationsOf the project. Let's look at these two pieces in more detail:

Most projects are not completely self-contained. they need files built by other projects in order to be compiled or tested and so on. for example, in order to use Hibernate in my project, I need to include some Hibernate jars in the classpath when I compile my source. to run my tests, I might also need to include some additional jars in the test classpath, such as a particle JDBC driver or the Ehcache jars.

These incoming files form the dependencies of the project. gradle allows you to tell it what the dependencies of your project are, so that it can take care of finding these dependencies, and making them available in your build. the dependencies might need to be downloaded from a remote Maven or Ivy repository, or located in a local directory, or may need to be built by another project in the same multi-project build. we call this processDependency resolution.

Note that this feature provides a major advantage over Ant. with Ant, you only have the ability to specify absolute or relative paths to specific jars to load. with Gradle, you simply declare the "names" of your dependencies, and other layers determine where to get those dependencies from. you can get similar behavior from Ant by adding Apache Ivy, but Gradle does it better.

// Note that this feature provides an important advantage over ant. To use ant, you can specify the jar package to be loaded by specifying the absolute or relative path, and use gradle, you only need to declare the name of the dependency, or other places where the dependency can be obtained. This can be achieved by adding Apache Ivy to ant, but gradle does better.

Often, the dependencies of a project will themselves have dependencies. for example, Hibernate core requires several other libraries to be present on the classpath with it runs. so, when Gradle runs the tests for your project, it also needs to find these dependencies and make them available. we call theseTransitive dependencies.

The main purpose of most projects is to build some files that are to be used outside the project. for example, if your project produces a Java library, you need to build a jar, and maybe a source jar and some documentation, and publish them somewhere.

These outgoing files form the publications of the project. gradle also takes care of this important work for you. you declare the publications of your project, and Gradle take care of building them and publishing them somewhere. exactly what "Hing" means depends on what you want to do. you might want to copy the files to a local directory, or upload them to a remote Maven or Ivy repository. or you might use the files in another project in the same multi-project build. we call this processPublication.

7.2. Declaring your dependencies

Let's look at some dependency declarations. Here's a basic build script:

// The following is a basic build script

Example 7.1. Declaring dependencies

build.gradle

apply plugin: 'java'repositories {    mavenCentral()}dependencies {    compile group: 'org.hibernate', name: 'hibernate-core', version: '3.6.7.Final'    testCompile group: 'junit', name: 'junit', version: '4.+'}

What's going on here? This build script says a few things about the project. firstly, it states that Hibernate core 3.6.7.Final is required to compile the project's production source. by implication, Hibernate core and its dependencies are also required at runtime. the build script also states that any junit> = 4.0 is required to compile the project's tests. it also tells Gradle to look in the Maven central repository for any dependencies that are required. the following sections go into the details.

7.3. Dependency configurations

In Gradle dependencies are groupedDeployments. A configuration is simply a named set of dependencies. We will refer to themDependency configurations.

// The dependency in gradle is configured as a group. A configuration is a set of simple dependent names. We call it configuration-dependent.

You can use them to declare the external dependencies of your project. As we will see later, they are also used to declare the publications of your project.

// We can use them to declare external dependencies. We will also see that they can also be used to declare the release of the project.

The Java plugin defines a number of standard ations. These configurations represent the classpaths that the Java plugin uses. Some are listed below, and you

Can find more details in Table 45.5, "Java plugin-dependency configurations ".

// The java Plug-In defines some standard configurations, as shown in the following section:

Compile

The dependencies required to compile the production source of the project.

// Compile the dependency of the project source code

Runtime

The dependencies required by the production classes at runtime. By default, also nodes the compile time dependencies.

//

TestCompile

The dependencies required to compile the test source of the project. By default, also nodes the compiled production classes and the compile time dependencies.

TestRuntime

The dependencies required to run the tests. By default, also nodes the compile, runtime and test compile dependencies.

Various plugins add further standard configurations. You can also define your own custom configurations to use in your build. Please see Section 23.3, "Dependency configurations" for the details of defining and customizing dependency configurations.

7.4. External dependencies

There are varous types of dependencies that you can declare. One such type isExternal dependency. This is a dependency on some files built outside the current build, and stored in a repository of some kind, such as Maven central, or a repository ate Maven or Ivy repository, or a directory in the local file system.

To define an external dependency, you add it to a dependency configuration:

// To define the external dependency, you need to add it to the dependency configuration.

Example 7.2. Definition of an external dependency

build.gradle

dependencies {    compile group: 'org.hibernate', name: 'hibernate-core', version: '3.6.7.Final'}

An external dependency is identified usinggroup,nameAndversionAttributes. Depending on which kind of repository you are using,groupAndversionMay be optional.

// The external dependency uses the group name and version attributes for life. The group and version attributes are optional.

The specified cut form for declaring external dependencies looks like"group:name:version".

// The simple description of the Life external dependency is as follows:group:name:version

Example 7.3. Define cut definition of an external dependency

build.gradle

dependencies {    compile 'org.hibernate:hibernate-core:3.6.7.Final'}

To find out more about defining and working with dependencies, have a look at Section 23.4, "How to declare your dependencies ".

7.5. Repositories

How does Gradle find the files for external dependencies? Gradle looks for them inRepository. A repository is really just a collection of files,

Organizedgroup,nameAndversion. Gradle understands several different repository formats, such as Maven and Ivy, and several different ways of accessing the repository, such as using the local file system or HTTP.

// How does gradle find these external dependencies? gradle willSearch in repository (repository. A repository is a collection of actually stored files, organized by group, name, and version. Gradle understands several different types of warehouse formats, such as maven, ivy, and gradle. It also understands different warehouse access methods, such as using a local file system or http

By default, Gradle does not define any repositories. You need to define at least one before you can use external dependencies. One option is use the Maven central repository:

// By default, gradle does not define any repositories. You need to define at least one repository before using external dependencies. One option is to use the Maven central repository.

Example 7.4. Usage of Maven central repository

build.gradle

repositories {    mavenCentral()}

Or Bintray's JCenter:

Example 7.5. Usage of JCenter repository

build.gradle

repositories {    jcenter()}

Or a any other remote Maven repository:

Example 7.6. Usage of a remote Maven repository

build.gradle

repositories {    maven {        url "http://repo.mycompany.com/maven2"    }}

Or a remote Ivy repository:

Example 7.7. Usage of a remote Ivy directory

build.gradle

repositories {    ivy {        url "http://repo.mycompany.com/repo"    }}

You can also have repositories on the local file system. This works for both Maven and Ivy repositories.

// You can also use the repository of the local file system, which can be used for both maven and ivy.

Example 7.8. Usage of a local Ivy directory

build.gradle

repositories {    ivy {        // URL can refer to a local directory        url "../local-repo"    }}

A project can have multiple repositories. Gradle will look for a dependency in each repository in the order they are specified, stopping at the first repository that contains the requested module.

// A project can have multiple warehouses. gradle searches for each warehouse in order defined by the warehouse. After finding the first warehouse containing this request module, it stops searching.

To find out more about defining and working with repositories, have a look at Section 23.6, "Repositories ".

7.6. Publishing artifacts

Dependency deployments are also used to publish files. [2] We call these filesPublication artifacts, Or usually justArtifacts.

// We call the published FilePublication artifacts orArtifacts

The plugins do a pretty good job of defining the artifacts of a project, so you usually don't need to do anything special to tell Gradle what needs to be published. however, you do need to tell Gradle where to publish the artifacts. you do this by attaching repositories touploadArchivesTask. Here's an example of publishing to a remote Ivy repository:

// You do not need to specify the content to be released, but you need to tell gradle where to publish artifacts.

Example 7.9. Publishing to an Ivy repository

build.gradle

uploadArchives {    repositories {        ivy {            credentials {                username "username"                password "pw"            }            url "http://repo.mycompany.com"        }    }}

Now, when you rungradle uploadArchives, Gradle will build and upload your Jar. Gradle will also generate and uploadivy.xmlAs well.

// When you runWhen the gradle uploadArchives command is run, gradle builds and uploads the jar package. Gradle also generates and uploads the ivy. xml file.

You can also publish to Maven repositories. the syntax is slightly different. [3] Note that you also need to apply the Maven plugin order to publish to a Maven repository. when this is in place, Gradle will generate and uploadpom.xml.

// You can also publish the file to the maven repository. The syntax is slightly different. Maven also generates and uploads the pom. xml file.

Example 7.10. Publishing to a Maven repository

build.gradle

apply plugin: 'maven'uploadArchives {    repositories {        mavenDeployer {            repository(url: "file://localhost/tmp/myRepo/")        }    }}

To find out more about publication, have a look at Chapter 30,Publishing artifacts.

7.7. Where to next?

For all the details of dependency resolution, see Chapter 23,Dependency Management, And for artifact publication see Chapter 30,Publishing artifacts.

If you are interested in the DSL elements mentioned here, have a lookProject.configurations{},Project.repositories{}AndProject.dependencies{}.

Otherwise, continue on to some of the other tutorials.