Выявление соглашений Gradle

Конфигурация по соглашению имеет много преимуществ, особенно с точки зрения краткости, потому что разработчикам не нужно явно настраивать вещи, которые неявно настраиваются с помощью соглашения. Однако, используя преимущества конфигурации по соглашению, нужно знать о соглашениях. Эти условные обозначения могут быть задокументированы, но мне всегда нравится, когда я могу программно определять условные обозначения, потому что документация может устареть (тот же принцип, лежащий в основе кода, всегда корректен, а комментарии только иногда верны). Я начну этот пост с рассмотрения того, как определить конкретные соглашения, связанные с плагином Gradle Java . Затем я обобщаю этот подход, чтобы определить все свойства, связанные со всеми задачами, связанными с корневым проектом сборки Gradle.

В документации Gradle на Gradle Plugins говорится следующее о важности Gradle Plugins и о том, что они добавляют в сборку Gradle:

Gradle по своей сути намеренно предоставляет мало полезных функций для автоматизации реального мира. Все полезные функции, такие как, например, возможность компилировать код Java, добавляются плагинами. Плагины добавляют новые задачи (например, JavaCompile), объекты домена (например, SourceSet), соглашения (например, основной источник Java находится в src / main / java), а также расширяют основные объекты и объекты из других плагинов.

В этом посте рассматриваются некоторые задачи, доменные объекты и соглашения, которые плагин Java вносит в сборку Gradle. Для начала мне нужен очень простой файл сборки Gradle. Он состоит исключительно из одной строки, которая применяет плагин Java. Это показано далее в файле build-java-plugin.gradle Gradle build-java-plugin.gradle .

встроенный Java-plugin.gradle

Имея этот однострочный файл сборки Gradle, легко увидеть, какие задачи Gradle предоставляет плагин, запустив команду gradle -b build-java-plugin.gradle tasks . На следующих двух снимках экрана показан результат запуска пустого файла сборки Gradle, за которым следует вывод запуска файла сборки Gradle только с применением плагина Java.

Сравнивая выходные данные запуска «задач» Gradle с пустым файлом сборки с результатами выполнения «задач» Gradle с файлом сборки с примененным плагином Java, мы видим, что Gradle имеет тот же набор «Задачи настройки сборки» и «Задачи справки», независимо от того, применяется плагин или нет. Что еще более важно, мы видим, что плагин Java добавляет много новых задач, классифицированных как «Задачи сборки» (сборка, сборка, buildDependents, buildNeeded, классы, clean, jar, testClasses), «Задачи документации» (javadoc), «Задачи проверки» ( проверить, проверить) и «Правила».

В Gradle 1.10 мне нравится одна особенность, которой не было в Gradle 1.8 (в предыдущей версии, которую я использовал), — возможность в командной строке запрашивать подробности о конкретной задаче Gradle . Это продемонстрировано на следующем снимке экрана для задач плагина Java compileJava , jar и javadoc . Все три задачи записываются в стандартный вывод с помощью команды help --task <task_name> в командной строке. Эти подробности о задачах Java Plugin также можно найти в Руководстве пользователя Gradle .

Поскольку Gradle построен на Groovy, довольно просто определить характеристики плагина Java с помощью «грубой силы». Следующий листинг кода для build-java-plugin-properties.gradle демонстрирует использование Groovy для определения свойств Gradle (тех, которые можно указать с помощью -P в отличие от системных свойств, указанных с помощью -D ), доступных сценарию сборки до и после применения плагина Java, а затем использует чрезвычайно удобный переопределенный оператор вычитания Groovy, чтобы найти различия. Имена и значения всех свойств, добавленных в скрипт Gradle плагином Java (за исключением свойства «properties»), представлены в алфавитном порядке.

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

Выход из запуска над скриптом Gradle для просмотра свойств плагина Java

Gradle позволяет легко увидеть все свойства Gradle с помощью команды « gradle properties », но это действие командной строки показывает все свойства независимо от их источника (самого Gradle или плагина).

Каждая задача Gradle, которую плагин Java добавляет в сборку, имеет свой собственный набор свойств. Эти свойства могут быть определены в Справочнике по языку сборки Gradle . Раздел « Типы задач» этого документа содержит ссылки на каждый тип задач. Страницы со ссылками на каждый тип задачи содержат сведения о свойствах, поддерживаемых этим типом задачи. Например, тип задачи JavaCompile указан на его странице как имеющий свойства, такие как classpath , destinationDir и source .

Следующий довольно обширный скрипт отображает параметры свойств задач Gradle Java Plugin compileJava, jar и javadoc. Этот скрипт демонстрирует, насколько мощным может быть применение Groovy для определения настроек сборки Gradle. Сценарий мог бы быть короче, если бы использовалось больше отражений, но явный вызов свойств задач имеет преимущества с точки зрения читабельности и как ссылка на то, какие свойства доступны в каждой задаче.

встроенный Java-плагин-metadata.gradle

Я использовал аннотацию Groovy @Field в этом файле сборки, чтобы сделать переменную, к которой она была применена, доступной для методов в файле сборки. Аннотация @Field не была доступна до Groovy 1.8, и это напомнило мне о чем-то еще важном, чтобы отметить здесь о Gradle и Groovy: Gradle использует свой собственный предварительно упакованный Groovy, а не любую другую версию Groovy, которая может быть установлена ​​на компьютере. Вы можете определить версию Groovy с помощью команды gradle --version . Следующий снимок экрана демонстрирует, что моя версия Groovy ( 2.1.6 ) отличается от версии Groovy (1.8.6), используемой в моей установке Gradle (Gradle 1.10). Поскольку Gradle 1.10 поставляется с Groovy 1.8.6 , в моем распоряжении была аннотация @Field .

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

Результат работы Gradle на build-java-plugin-metadata.gradle

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

встроенный Java-плагин-метаданные reflection.gradle

Поскольку эти выходные данные относятся ко всем свойствам, связанным со всеми задачами, связанными с корневым проектом сборки Gradle, выходные данные слишком длинные, чтобы включать их здесь. Не во всех экземплярах значений свойств есть классы, для обработки которых подготовлен метод extractStringRepresentation (Object object), но эти случаи можно добавить в структуру if-else if этого метода для их обработки. Эта версия сборки Gradle является более общей, чем предыдущая, и распечатывает свойства, связанные с заданиями, сгруппированными по заданию.

Поскольку сборка Gradle тесно связана с Groovy, синтаксис и функции Groovy можно использовать для получения дополнительных сведений о сборке Gradle. Примеры в этом посте воспользовались многочисленными тонкостями Groovy. Причина, по которой приведенный выше код сборки Gradle является настолько многословным, заключается в том, что большинство классов Gradle, используемых для значений свойств, НЕ имеют переопределенных методов toString (), и поэтому не показан действительно полезный вывод без специального кода, вызывающего конкретные методы для получения полезных представлений. Я не делал этого в примерах этого поста, но другой вариант для решения проблемы отсутствия переопределенных методов toString() — использовать возможности перехвата Groovy ( metaClass.invokeMethod ) для перехвата вызовов toString() и предоставления переопределенной версии. По сути, это будет тот же код, который использовался выше, но будет инкапсулирован в перехватывающие объекты, а не содержится в коде сценария.

Вывод

Gradle имеет действительно хорошую документацию (особенно руководство пользователя Gradle и справочник по языку сборки Gradle ), и большинство задач и свойств, связанных с плагином Java для Gradle (и другими плагинами), легко доступны из этой документации. Тем не менее, мне нравится знать, как программно определять важные соглашения в случае, если документация когда-либо ошибается, или я использую версию, отличную от поддерживаемой документации. Другая цель этого поста — продемонстрировать, насколько полезно знать Groovy при работе с Gradle. Именно по этой причине я считаю, что растущая известность Gradle не может не повысить интерес к Groovy.