Глава 2. Обзор.

2.1 Возможности.

Ниже представлены некоторые из возможностей Gradle.

Декларативные сборки и сборки-по-соглашению.

В самом сердце Gradle лежит богатый расширяемый DSL (Domain Specific Language) основанный на Groovy. Предоставляя декларативные элементы языка, которые вы можете соединять как вашей душе угодно, Gradle продвигает декларативные сборки на следующий уровень. Также эти элементы предоставляют поддержку сборки-по-соглашению для Java, Groovy, OSGi, Web и Scala проектов. Более того, этот язык расширяемый. Добавляйте новый элементы или расширяйте существующий, тем самым обеспечивая краткие, поддерживаемые и понятные сборки.

Язык для программирования зависимостей.

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

Структурирует вашу сборку.

Гибкость и богатство Gradle в конечном счете позволяет вам применять общие принципы дизайна для вашей сборки. Например, очень просто составить вашу сборку из переиспользуемых кусочков логики. Встроить вещи, где ненужные обходные пути будут неуместны. Он не будет заставлять вас разделять то, что должно быть вместе (например, в иерархии вашего проекта). Избегает таких "запашков", как куча маленьких изменений или расходящееся изменение, которое превратит вашу сборку в настоящий ад для поддержки. Наконец, вы сможете создать хорошо структурированную, легко поддерживаемую, понятную сборку.

Глубокое API.

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

Gradle масштабируется.

Gradle очень хорошо масштабируется. Он значительно увеличивает вашу продуктивность, что в сборке простого одиночного проекта, что в громадной многопроектной сборке в компании. Это же справедливо и для структурирования сборки. С современной функцией инкрементной сборки так же можно победить проблему производительности, от которой страдает множество больших проектов в компаниях.

Многопроектные сборки.

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

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

Много вариантов для управления зависимостями

Разные команды предподчитают разные пути для управления внешними зависимостями. Gradle предоставляет удобную поддержку для любой стратегии. От переходящего управления зависимостями с использованием Maven или Ivy хранилищ до jar-файлов и папок на локальной машине.

Gradle - первый интеграционный инструмент сборки.

Задачи Ant - первоклассные объекты. Что более интересно, проекты Ant тоже первоклассные объекты. Gradle предоставляет глубокий импорт для любого Ant-проекта, превращая Ant-цели в нативные задачи во время выполнения. Вы можете полагаться на них из Gradle, можете их расширять, даже можете объявлять зависимости на задачи Gradle в вашем build.xml. Такая же интеграция предоставляется для свойств, путей и так далее...

Gradle полностью поддерживает вашe существующую инфраструктуру Maven или Ivy хранилищ для публикации или извлечения зависимостей. Еще он предоставляет ковертер для превращения Maven'овского pom.xml в Gradle'овский скрипт. В ближайщем будущем появятся импорты из Maven-проектов во время выполнения.

Легкая миграция.

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

Groovy.

Сборочные скрипты написаны на Groovy, не на XML. Но в отличие от других подходов, этот не просто для показа чистой скриптовой мощи динамического языка. Это просто вело бы к трудноподдерживаемой сборке. Весь дизайн Gradle ориентирован на то, чтобы использоваться как язык, а не жесткий каркас. И Groovy - это клей, который позволяет вам рассказать вашу индивидуальную историю с использованием абстракций, предоставляемых Gradle (или вами). Gradle предоставляет несколько типовых историй, но у них нет каких-либо особых привилегий. Это самая важная особенность в сравнении с другими декларативными системами сборки. Поддержка Groovy не просто "сахар". Gradle API полностью Goovy'ирован. Добавление Groovy становится в результате приятным и продуктивным опытом.

Gradle Wrapper.

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

Бесплатный и открытый.

Gradle - проект с открытым исходным кодом и лицензирован под Apache Software License.



2.2 Почему Groovy?

Создатели Gradle думают, что преимущества внутреннего DSL (основанного на динамическом языке) над XML потрясающи, когда он используется в сборочных скриптах. Существует достаточное количество динамических языков. Почему Groovy? Ответ лежит в контексте, в котором действует Gradle. Хотя Gradle и инструмент сборки общего назначения по своей сущности, его основной фокус - Java проекты. В таких проектах, члены команды будут близко знакомы с Java. Создатели Gradle считают, что сборка должна быть прозрачной насколько это возможно для всех членой команды.

В этом случае вы могли бы поспорить, почему бы им просто не использовать Java как язык для сборочных скриптов. Это обоснованный вопрос. Использование Java было бы в наивысшей степени прозрачно для вашей команды и имело бы наименьшую кривую обучения, но из-за ее ограничений, такой сборочный язык не был приятным, выразительным и мощным. Такие языки как Python, Groovy или Ruby лучше всего подходят для этой ниши. Создатели выбрали Groovy, так как он предлагает наибольшую прозрачность для людей из мира Java. Его базовый синтакс такой же как и у Java, это же касается и системы типов, структуры пакетов и других вещей. Groovy предоставляет намного больше этого, но основой является Java.

Для разработчиков Java со знанием Python или Ruby или желанием изучить их, аргументы выше не подходят. Дизайн Gradle хорошо подходит для создания другого "движка" сборочных скриптов на JRuby или Jython. Для создателей Gradle на данный момент это не является наивысшим приоритетом, но они с удовольствием поддержает попытку создания дополнительных "движков" сборочных скриптов.