Я ссылаюсь на два урока, чтобы написать ответ один , два
Gradle - это универсальный, декларативный инструмент для сборки. Это общая цель, потому что она может быть использована для создания практически всего, что вы хотите реализовать в сценарии сборки. Это декларативно, так как вы не хотите видеть много кода в файле сборки, который не читается и менее удобен в обслуживании. Таким образом, хотя Gradle предоставляет идею соглашений и простой и декларативной сборки, он также делает инструмент адаптируемым и расширяет возможности разработчиков. Он также предоставляет простой способ настройки поведения по умолчанию и различных хуков для добавления сторонних функций.
Gradle объединяет в себе все преимущества обоих инструментов, предоставляет дополнительные функции и использует Groovy в качестве языка, специфичного для домена (DSL). Он обладает мощью и гибкостью инструмента Ant с такими функциями Maven, как жизненный цикл сборки и простота использования.
Почему Градл? Почему сейчас?
Ответ инструмента сборки - добавить функциональность сценариев с помощью нестандартных механизмов расширения. Вы заканчиваете тем, что смешиваете код сценария с XML или вызываете внешние сценарии из своей логики сборки. Легко представить, что вам нужно будет со временем добавлять все больше и больше пользовательского кода. В результате вы неизбежно вносите случайную сложность, и ремонтопригодность выходит за рамки.
Допустим, вы хотите скопировать файл в определенное место при создании релизной версии вашего проекта. Чтобы определить версию, вы проверяете строку в метаданных, описывающую ваш проект. Если он соответствует определенной схеме нумерации (например, 1.0-RELEASE), вы копируете файл из точки A в точку B. С внешней точки зрения это может показаться тривиальной задачей. Если вам приходится полагаться на XML, язык сборки многих традиционных инструментов, выражающих эту простую логику, становится довольно сложным.
Эволюция инструментов сборки Java
Логика сборки Java должна быть описана в XML. XML отлично подходит для описания иерархических данных, но ему не хватает выражения программного потока и условной логики. По мере усложнения сценария сборки поддержание кода сборки становится кошмаром.
В Ant вы делаете цель JAR зависимой от цели компиляции. Муравей не дает никаких указаний о том, как структурировать ваш проект. Хотя это обеспечивает максимальную гибкость, Ant делает каждый скрипт сборки уникальным и трудным для понимания. Внешние библиотеки, необходимые для вашего проекта, обычно проверяются на контроль версий, потому что нет никакого автоматизированного механизма для их извлечения из центрального расположения.
Maven 1 , выпущенный в июле 2004 года, попытался облегчить этот процесс. Он предоставил стандартизированную структуру проекта и каталога, а также управление зависимостями. К сожалению, пользовательскую логику сложно реализовать
Gradle вписывается в это поколение инструментов сборки и удовлетворяет многим требованиям современных инструментов сборки (рисунок 1). Это обеспечивает выразительный DSL, соглашение по конфигурации подхода и мощное управление зависимостями. Это делает правильный шаг, чтобы отказаться от XML и представить динамический язык Groovy для определения вашей логики сборки. Звучит убедительно, не так ли?
Gradle сочетает в себе лучшие функции других инструментов сборки.
Необыкновенный набор функций Gradle
Зачем создавать свои проекты Java с Gradle, а не с Ant или Maven?
Инструмент сборки по умолчанию для Android (и новая звезда инструментов сборки в JVM) предназначен для упрощения создания сценариев сложных многоязычных сборок. Стоит ли переходить на него, если вы используете Ant или Maven?
Ключ к разблокировке мощных функций Gradle в вашем скрипте сборки заключается в обнаружении и применении его доменной модели, как показано на рисунке ниже.
Gradle не может знать все требования, специфичные для вашей корпоративной сборки. Предоставляя перехватчики на этапах жизненного цикла, Gradle позволяет отслеживать и настраивать поведение выполнения сценария сборки.
Gradle устанавливает словарь для своей модели, выставляя DSL, реализованный в Groovy. При работе со сложной проблемной областью в этом случае мощным инструментом может быть задача создания программного обеспечения, позволяющего использовать общий язык для выражения вашей логики.
Другой пример - способ выражения зависимостей во внешних библиотеках, очень распространенная проблема, решаемая инструментами сборки. Готовый Gradle предоставляет вам два блока конфигурации для вашего скрипта сборки, которые позволяют вам определить зависимости и репозитории, из которых вы хотите их получить. Если стандартные элементы DSL не соответствуют вашим потребностям, вы даже можете ввести свой собственный словарь через механизм расширения Gradle.
Интеграция с другими инструментами сборки
Gradle хорошо играет с муравьями предшественника, Maven и Ivy, как показано на рисунке ниже.
Автоматизация вашего проекта от сборки до развертывания
На изображении: этапы конвейера развертывания.
Компиляция кода
Работающие юнит и интеграционные тесты
Выполнение статического анализа кода и создание тестового покрытия
Создание дистрибутива
Обеспечение целевой среды
Развертывание результата
Выполнение дымовых и автоматических функциональных испытаний
Я ссылаюсь на два урока, чтобы написать ответ один , два
