Глава 7. Основы управления зависимостями.

В этой главе представляются основы управления зависимостями в Gradle.

7.1. Что такое управление зависимостями?

Грубо говоря, управление зависимостями состоит из двух частей. Первая часть, Gradle необходимо знать о вещах, в которых ваш проект нуждается, чтобы собраться или запуститься, для того, чтобы найти их. Мы называем такие входные файлы - зависимостями проекта. Вторая часть, Gradle необходимо собрать и выгрузить вещи, которые ваш проект выдает. Мы называем такие выходные файлы - публикации проекта. Дайте посмотрим на эти части более детально:

Большинство проектов не замкнуты. Им нужны файлы, собранные другими проектами, для того, чтобы быть скомпилированными или протестированными и так далее. Например, для того, чтобы использовать Hibernate в проекте, нужно подключить некоторые его jar-файлы в путь к классам, когда проект компилируется. Для запуска тестов, также может быть необходимо подключить дополнительные jar-файлы в тестовый путь к класса, таким как определенный JDBC драйвер или jar-файлы Ehcache.

Такие входные файлы формируют зависимости проекта. Gradle позволяет сказать каковы зависимости вашего проекта, чтобы позабоиться об их поиске и сделать доступными для вашей сборки. Зависимости могут быть загружены из удаленных хранилищ Maven или Ivy или находится в локальной папке или могут быть собраны другим проектом в одной многопроектной сборке. Мы называет этот процесс разрешением зависимостей.

Обратите внимание, что эта возможность является большим преимуществом над Ant. С Ant, у вас была возможность только указать абсолютный или относительный путь для загрузки определенных jar-файлов. С Gradle, вы просто определяете "наименования" ваших зависимостей и другие слои определяют откуда можно их получить. Вы можете добиться такого же поведения от Ant, добавить Apache Ivy, но Gradle делает это лучше.

Довольно часто, зависимости проекта сами имеют зависимости. Например, ядро Hibernate требует, чтобы несколько других библиотек находились в пути к классам, для его запуска. Так что, когда Gradle запускает тесты для вашего проекта, ему также надо найти эти зависимости и сделать их доступными. Мы называет их переходными зависимостями.

Главная цель большинства проектов, собрать некоторые файлы, которые будут использованы за пределами проекта. Например, если ваш проект выдает Java-библиотеку, то ваш надо собрать jar-файл, и возможно jar-файл с исходными кодами, и какую-либо документацию, опубликовать это где-нибдуь.

Эти выходные файлы формируют публикации проекта. Gradle также заботиться об этой важной работе для вас. Вы определяете публикации вашего проекта и Gradle берет на себя заботу об их сборке и публикации где-либо. Точно значение слова "публикация" зависит от того, что вы хотите сделать. Вы можете захотеть скопировать файлы с локальную папку или выгрузить их в удаленное хранилище Maven или Ivy. Или можете захотеть использовать файлы в другом проекте в той же многопроектной сборке. Мы называем этот процесс публикацией.

7.2. Объявление ваших зависимостей.

Давайте взглянем на некоторые объявления зависимостей. Ниже приведет основной сборочный скрипт:

Пример 7.1. Объявление зависимостей

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.+'
}
	  

Что же здесь происходит? Этот сборочный скрипт говорит несколько вещей о проекте. Первое, он устанавливает, что для компиляции производственных исходных кодов проекта требуется ядро Hibernate 3.6.7.Final. Отсюда вывод, что во время выполнения требуется ядро Hibernate и его зависимости. Сборочный скрипт также говорит, что для компиляции тестов проекта, требуется junit >= 4.0. В нем также говорится, что искать любые зависимости надо в центральном хранилище Maven. Следующие секции описывают детали.

7.3. Конфигурации зависимостей.

В Gradle зависимости сгруппированы в конфигурации. Конфигурация всего лишь именованный набор зависимостей. Мы ссылаемся на них как конфигурации зависимостей. Мы можете их использовать для объявления внешних зависимостей проекта. Как мы увидим позже, они также используются для объявления публикаций вашего проекта.

Плагин Java определяет множество стандартных конфигураций. Эти конфигурации представляют собой пути к классам, которые плагин использует. Ниже перечислены некоторые из конфигураций. Вы можете найти больше информации в Таблице 47.5 "Плагин Java - конфигурации зависимостей".

compile

Зависимости, требуемые для компиляции производственного кода проекта.

runtime

Зависимости, требуемые производственными классами во время выполнения. По умолчанию, включают зависимости времени компиляции.

testCompile

Зависимости, требуемые для компиляции тестового кода проекта. По умолчанию, включают скомпилированные производственные классы и зависимости времени компиляции.

testRuntim

Зависимости, требуемые для запуска тестов. По умолчанию, включают зависимости компиляции, времени выполнения и компиляции тестов.

Различные плагины добавляют еще больше стандартных конфигураций. Вы можете сами определить собственные конфигурации, для использования в ваших сборках. Смотрите Секцию 25.3 Конфигурции зависимостей для детальной информации об определении и настройке конфигураций зависимости.

7.4. Внешние зависимости.

Вы можете объявлять различные типы зависимостей. Один из типов - внешняя зависимость. Зависимость на файлы, собранные за пределами текущей сборки и хранящиеся в хранилище типа цетрального Maven, или корпоративного Maven, или Ivy, или в папке на локальной машине.

Для определения внешней зависимости, вы добавляете ее к конфигурации зависимости:

Пример 7.2. Определение внешней зависимости

build.gradle

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

Внешняя зависимость определена атрибутами group, name и version. В зависимости от типа хранилища, group и version могут быть необязательными.

Краткая форма объявления внешней зависимости выглядит приблизительно так "group:name:version:".

Пример 7.3. Краткое определение внешней зависимости

build.gradle

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

Хотите узнать больше об определении и работы с зависимостями, взгляните на Секцию 25.4 "Как объявлять ваши зависимости".

7.5. Хранилища.

Как Gradle находит файлы для внешних зависимостей? Он ищет их в хранилищах. Хранилище - это в действительности просто коллекция файлов, организованных по группе, имени и версии. Gradle понимает несколько различных форматов хранилищ, таких как Maven или Ivy, и несколько разных способов для доступа к ним, например, использование локальной файловой системы или HTTP.

По умолчанию, Gradle не определяет никаких хранилищ. Вам необходимо определить хотя бы одно, перед тем, как вы сможете использовать внешние зависимости. Один из вариантов, использовать центральное хранилище Maven:

Пример 7.4. Использование центрального хранилища Maven

build.gradle

repositories {
    mavenCentral()
}
	  

Или JCenter от Bintray:

Пример 7.5. Использование хранилища JCenter

build.gradle

repositories {
    jcenter()
}
	  

Или любого друго хранилища Maven:

Пример 7.6. Использование удаленного хранилища Maven

build.gradle

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

Или удаленного хранилища Ivy:

Пример 7.7. Использование удаленной папки Ivy

build.gradle

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

У вас также могут быть хранилища в локальной файловой системе. Работает для обоих, Maven и Ivy, типов хранилищ.

Пример 7.8. Использование локальной папки Ivy

build.gradle

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

У проекта может быть несколько хранилищ. Gradle ищет зависимость в каждом хранилище в том порядке, в котором они определены, останавливаясь на первом, в котором найдет запрашиваемый модуль.

Чтобы узнать больше об определении и работе с хранилищами, взгляните на Секцию 25.6 "Хранилища".

7.6. Публикация артефактов.

Конфигурации зависимостей также используются для публикации файлов. Мы называем их артефактами публикации или просто артефактами.

Плагины делают большую часть работы по определению артефактов проекта, так что вам обычно не надо делать ничего особого, чтобы сказать Gradle что необходимо опубликовать. Однако, вам нужно сказать Gradle куда публиковать артефакты. Это делается прикреплением хранилищ к задаче uploadArchives. Ниже пример публикации в удаленное хранилище Ivy:

Пример 7.9. Публикация в хранилище Ivy

build.gradle

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

Теперь, когда вы запускаете команду gradle uploadArchives, Gradle соберет и выгрузит ваш jar-файл. Он также сгенерирует и выгрузит ivy.xml.

Также, вы можете публиковать в хранилища Maven. Синтакс немного отличается. Обратите внимание, что вам необходимо применить плагин Maven, для того, чтобы публиковать в такие типы хранилищ. Когда все будет сделано, Gradle сгенерирует и выгрузит pom.xml.

Пример 7.10. Публикация в хранилище Maven

build.gradle

apply plugin: 'maven'

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

Чтобы узнать больше о публикации, взгляните на Главу 32 "Публикация артефактов".

7.7. Что дальше?

Для полной информации о разрешении зависимостей, смотрите Главу 25 "Управление зависимостями", для публикации артефактов, Главу 32 "Публикация артефактов".

Если вас заинтересовали элементы DSL, упомянутые в этой главе, взгляните на roject.configurations{}, Project.repositories{} и Project.dependencies{}.