Файл: Gradle.pdf

8

Dependency Management Basics

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

8.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 files the dependencies of the project. Secondly, Gradle needs to build and upload the things that your project produces. We call these outgoing files the publications of the project. Let' 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 particular 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 process dependency resolution.

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 these transitive 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 "publishing" 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

Page 45 of 343

repository. Or you might use the files in another project in the same multi-project build. We call this process publication.

8.2. Declaring your dependencies

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

Example 8.1. Declaring dependencies

build.gradle

apply plugin: 'java'

repositories { mavenCentral()

}

dependencies {

compile group: 'org.hibernate', name: 'hibernate-core', version: '3.6.7.Fi 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 tha 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 Mave central repository for any dependencies that are required. The following sections go into the details.

8.3. Dependency configurations

In Gradle dependencies are grouped into configurations. A configuration is simply a named set of dependencies. We will refer to them as dependency configurations. 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.

The Java plugin defines a number of standard configurations. These configurations represent the classpaths that the Java plugin uses. Some are listed below, and you can find more details in Table 23.5, “Java plugin - dependency configurations”.

compile

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

runtime

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

testCompile

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

Page 46 of 343

testRuntime

The dependencies required to run the tests. By default, also includes 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 43.3, “Dependency configurations”for the details of defining and customizing dependency configurations.

8.4. External dependencies

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

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

Example 8.2. Definition of an external dependency

build.gradle

dependencies {

compile group: 'org.hibernate', name: 'hibernate-core', version: '3.6.7.Fi

}

An external dependency is identified using group, name and version attributes. Depending on which kind of repository you are using, group and version may be optional.

There is a shortcut form for declaring external dependencies, which uses a string of the form "grou

.

Example 8.3. Shortcut 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 43.4, “Ho to declare your dependencies”.

8.5. Repositories

How does Gradle find the files for external dependencies? Gradle looks for them in a repository. A repository is really just a collection of files, organized by group, name and version. 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.

By default, Gradle does not define any repositories. You need to define at least one before you can

Page 47 of 343

use external dependencies. One option is use the Maven central repository:

Example 8.4. Usage of Maven central repository

build.gradle

repositories { mavenCentral()

}

Or a remote Maven repository:

Example 8.5. Usage of a remote Maven repository

build.gradle

repositories { maven {

url "http://repo.mycompany.com/maven2"

}

}

Or a remote Ivy repository:

Example 8.6. 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.

Example 8.7. 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.

To find out more about defining and working with repositories, have a look at Section 43.6,

Page 48 of 343

“Repositories”.

8.6. Publishing artifacts

Dependency configurations are also used to publish files.[3] We call these files publication artifacts, or usually just artifacts.

The plugins do a pretty good job of defining the artifacts of a project, so you usually don't need t 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 to the uploadArchives task. Here's an example of publishing to a remote Ivy repository:

Example 8.8. Publishing to an Ivy repository

build.gradle

uploadArchives { repositories {

ivy { credentials {

username "username" password "pw"

}

url "http://repo.mycompany.com"

}

}

}

Now, when you run gradle uploadArchives, Gradle will build and upload your Jar. Gradle will also generate and upload an ivy.xml as well.

You can also publish to Maven repositories. The syntax is slightly different.[4] Note that you also need to apply the Maven plugin in order to publish to a Maven repository. In this instance, Gradle will generate and upload a pom.xml.

Example 8.9. 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 44, Publishing artifacts.

Page 49 of 343

8.7. Where to next?

For all the details of dependency resolution, see Chapter 43, Dependency Management, and for artifact publication see Chapter 44, Publishing artifacts.

If you are interested in the DSL elements mentioned here, have a look at

Project.configurations{}, Project.repositories{} and Project.dependencies{}

.

Otherwise, continue on to some of the other tutorials.

[3] We think this is confusing, and we are gradually teasing apart the two concepts in the Gradle DSL.

[4] We are working to make the syntax consistent for resolving from and publishing to Maven repositories.

Page 50 of 343

9

Groovy Quickstart

To build a Groovy project, you use the Groovy plugin. This plugin extends the Java plugin to add Groovy compilation capabilities to your project. Your project can contain Groovy source code, Java source code, or a mix of the two. In every other respect, a Groovy project is identical to a Java project, which we have already seen in Chapter 7, Java Quickstart.

9.1. A basic Groovy project

Let's look at an example. To use the Groovy plugin, add the following to your build file:

Example 9.1. Groovy plugin

build.gradle

apply plugin: 'groovy'

Note: The code for this example can be found at samples/groovy/quickstart which is in both the binary and source distributions of Gradle.

This will also apply the Java plugin to the project, if it has not already been applied. The Groovy plugin extends the compile task to look for source files in directory src/main/groovy, and the c task to look for test source files in directorysrc/test/groovy. The compile tasks use joint compilation for these directories, which means they can contain a mixture of java and groovy source files.

To use the groovy compilation tasks, you must also declare the Groovy version to use and where to find the Groovy libraries. You do this by adding a dependency to the groovy configuration. The configuration inherits this dependency, so the groovy libraries will be included in classpath when compiling Groovy and Java source. For our sample, we will use Groovy 1.6.0 from the public Maven repository:

Page 51 of 343

Example 9.2. Dependency on Groovy 1.6.0

build.gradle

repositories { mavenCentral()

}

dependencies {

groovy group: 'org.codehaus.groovy', name: 'groovy', version: '1.7.10'

}

Here is our complete build file:

Example 9.3. Groovy example - complete build file

build.gradle

apply plugin: 'eclipse' apply plugin: 'groovy'

repositories { mavenCentral()

}

dependencies {

groovy group: 'org.codehaus.groovy', name: 'groovy', version: '1.7.10' testCompile group: 'junit', name: 'junit', version: '4.8.2'

}

Running gradle build will compile, test and JAR your project.

9.2. Summary

This chapter describes a very simple Groovy project. Usually, a real project will require more than this. Because a Groovy project is a Java project, whatever you can do with a Java project, you can also do with a Groovy project.

You can find out more about the Groovy plugin in Chapter 24, The Groovy Plugin, and you can find more sample Groovy projects in the samples/groovy directory in the Gradle distribution.

Page 52 of 343