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

В этой главе описывается оригинальный механизм публикации, доступный в Gradle 1.0: в Gradle 1.3 был представлен новый механизм публикации. Хотя этот новый механизм инкубационный и все еще не завершен, он представляет некоторые новые идеи и возможности, которые делают (и будут делать) публикацию Gradle еще более мощной.

Вы можете прочитать о новых плагинах публикации в Главе 35 Публикация Ivy (новая) и Главе 36 Публикация Maven (новая).

32.1. Введение.

В этой главе описывается как объявить исходящие артефакты вашего проекта и с ними работать (например, выгрузить их). Мы определяем артефакты проекта как файлы, которые проекты предоставляет внешнему миру. Это может быть библиотека или zip-дистрибутив, или любой другой файл. Проект может опубликовать любой количество артефактов.

32.2. Артефакты и конфигурации.

Так же как и зависимости, артефакты сгруппированы в конфигурации. Фактически, конфигурация может содержать и артефакты, и зависимости в одно и то же время.

Для каждой конфигурации в вашем проекте, Gradle предоставляет задачи uploadConfigurationName и buildConfigurationName (где ConfigurationName - имя конкретной конфигурации). При выполнении, эти задачи соберут или выгрузят артефакты принадлежащие соответствующей конфигурации.

Таблица 47.5 Плагин Java - конфигурации зависимостей показывает конфигурации, доабвленные плагином Java. Две из них важны для использования с артефактами. Конфигурация archives - стандартная конфигурация для присвоения ваших артефактов. Плагин Java автоматически присваивает jar-файлы по умолчанию этой конфигурации. О конфигурации runtime мы еще поговорим в Секции 32.5 Еще о библиотеках проекта. Так же как с зависимостями, вы можете объявить столько пользовательских конфигураций, сколько захотите и присвоить артефакты им.

32.3. Объявление артефактов.

32.3.1. Артефакты задач архивирования.

Вы можете использовать задачу архивирования, чтобы определить артефакт:

Пример 32.1. Определение артефакта с использованием задачи архивирования

build.gradle

task myJar(type: Jar)

artifacts {
    archives myJar
}
	  

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

32.3.2. Файловые артефакты.

Вы можете использовать файл, для определения артефакта:

Пример 32.2. Определение артефакта с использованием файла

build.gradle

def someFile = file('build/somefile.txt')

artifacts {
    archives someFile
}
	  

Gradle вычислит свойства артефакта, основываясь на имени файла. Вы можете настроить эти свойства:

Пример 32.3. Настройка артефакта

build.gradle

task myTask(type:  MyTaskType) {
    destFile = file('build/somefile.txt')
}

artifacts {
    archives(myTask.destFile) {
        name 'my-artifact'
        type 'text'
        builtBy myTask
    }
}
	  

Есть синтаксис, основанный для ассоциативных массивах, для определения артефакта с использованием файла. Ассоциативный массив должен включать элемент file, который определяет файл. Ассоциативный массив может включать другие свойства артефакта:

Пример 32.4. Синтаксис ассоциативного массива для определения артефакта с использованием файла

build.gradle

task generate(type:  MyTaskType) {
    destFile = file('build/somefile.txt')
}

artifacts {
    archives file: generate.destFile, name: 'my-artifact', type: 'text', builtBy: generate
}
	  

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

Мы уже говорили, что есть специальные задачи выгрузки для каждой конфигурации. До того, как вы сможете произвести выгрузку, вы должны настроить задачу и указать куда публиковать артефакты. Определенные вами хранилища (как описано в Секции 25.6 Хранилища) не используются автоматически для выгрузки. Фактически, для некоторых из этих хранилищ поддерживаются только скачивание артефактов, а не выгрузка. Вот пример того, как вы можете настроить задачу выгрузки для конфигурации:

Пример 32.5. Настройка задачи выгрузки

build.gradle

repositories {
    flatDir {
        name "fileRepo"
        dirs "repo"
    }
}

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

Как вы можете видеть, можно либо использовать ссылку на существующее хранилище, либо создать новое. Как описано в Секции 25.6.9 Снова о распознавателях Ivy, вы можете использовать все распознователи Ivy, подходящие выгрузки.

Если хранилище выгрузки определено с несколькими шаблонами, Gradle должне выбрать шаблон для использования для выгрузки каждого файла. По умолчанию, Gradle выгрузит по шаблону, определенному параметром url, соединенному с необязательным параметром layout. Если параметр url не предоставлен, тогда Gradle будет использовать первый определенный artifactPattern для выгрузки или первый определенный ivyPattern для выгрузки файлов Ivy, если они заданы.

Выгрузка в хранилище Maven описано в Секции 33.6 Взаимодействие с хранилищами Maven.

32.5. Еще о библиотеках проекта.

Если предполагается, что ваш проект будет использоваться как библиотека, вам нужно определить артефакты этой библиотеки и зависимости этих артефактов. Плагин Java добавляет конфигурацию runtime для этой цели, с неявным предположением, что зависимости времени выполнения - зависимости, которые ваш артефакт хочет опубликовать. Конечно, это полностью настраиваемо. Вы можете добавить свою собственную пользовательскую конфигурацию или позволить существующим конфигурациям расширять другие. У вас могут быть различные группы артефактов, которые имеют различные наборы зависимостей. Это очень мощный и гибкий механизм.

Если кто-то хочет использовать ваш проект как библиотеку, ему просто необходимо объявить какая конфигурация зависимостей зависит от какой. Зависимость Gradle предоставляем свойство configuration для объявления этого. Если оно не задано, используется конфигурация default (смотрите Секцию 25.4.9 Конфигурации зависимости). Использование вашего проекта в качестве библиотеки, может случиться в рамках многопроектной сборки или при извлечении вашего проекта из хранилища. В последнем случае, предполагается, что вся нужная иформация содержится в описании ivy.xml. Если вы работаете с хранилищами Maven, то у вас нет такой гибкости. Чтобы узнать как публиковать в хранилище Maven, смотрите Секцию 33.6 Взаимодействие с хранилищами Maven.