Зачем использовать Gradle вместо Ant или Maven?

Я сам не использую Gradle в гневе (пока это просто игрушечный проект) [автор имеет в виду, что они до сих пор использовали Gradle только в игрушечном проекте, не то, чтобы Gradle был игрушечным проектом - см. комментарии], но я бы сказал, что причины, по которым можно было бы подумать об его использовании, были бы из-за разочарования Ant и Maven .

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

Maven использует противоположный подход и ожидает от вас полной интеграции с жизненным циклом Maven. Опытных пользователей Ant это особенно раздражает, поскольку Maven лишает вас многих свобод, которые есть в Ant. Например, есть блог Sonatype. это перечисляет многие критические замечания Maven и их ответы.

Механизм плагинов Maven позволяет создавать очень мощные конфигурации сборки, а модель наследования означает, что вы можете определить небольшой набор родительских POM, инкапсулирующих ваши конфигурации сборки для всего предприятия, и отдельные проекты могут наследовать эти конфигурации, оставляя их легковесными. Конфигурация Maven очень многословна (хотя Maven 3 обещает решить эту проблему), и если вы хотите сделать что-то, что не соответствует Maven, вам нужно написать плагин или использовать хакерскую интеграцию с Ant. Примечание. Мне нравится писать плагины Maven, но я понимаю, что многие будут возражать против прилагаемых усилий.

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

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

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

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

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

Помимо этих функций программирования зависимостей, Gradle добавляет функции зависимости проекта и JAR за счет интеграции с Apache Ivy. Как вы знаете, Ivy — гораздо более мощный и гораздо менее самоуверенный инструмент управления зависимостями, чем, скажем, Maven.

Gradle обнаруживает зависимости между проектами и между проектами и JAR-файлами. Gradle работает с репозиториями Maven (загрузка и выгрузка), такими как iBiblio, или вашими собственными репозиториями, но также поддерживает и другую инфраструктуру репозитория, которая может у вас быть.

В многопроектных сборках Gradle одновременно адаптируется и адаптируется к структуре и архитектуре сборки. Вам не нужно адаптировать свою структуру или архитектуру к инструменту сборки, как это требуется для Maven.

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

Это может быть немного спорным, но Gradle не скрывает того факта, что это полноценный язык программирования.

Ant + ant-contrib — это, по сути, полный по Тьюрингу язык программирования, на котором никто не хочет программировать.

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

• Он следует конвенциональной конфигурации (аля Maven), но только в той степени, в которой вы этого хотите.
• Это позволяет вам писать гибкие пользовательские задачи, как в Ant
• Он обеспечивает поддержку многомодульных проектов, которая превосходит Ant и Maven.
• У него есть DSL, который делает 80% вещей простыми, а 20% возможными (в отличие от других инструментов сборки, которые делают 80% простыми, 10% возможными и 10% фактически невозможными).

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

Gradle прекрасно сочетает в себе Ant и Maven, взяв лучшее из обоих фреймворков. Гибкость от Ant и соглашения по настройке, управлению зависимостями и плагинам от Maven.

Итак, если вы хотите иметь стандартную сборку Java, например, в maven, но тестовая задача должна выполнить какой-то нестандартный шаг, это может выглядеть так, как показано ниже.

build.gradle:

apply plugin:'java'
task test{
  doFirst{
    ant.copy(toDir:'build/test-classes'){fileset dir:'src/test/extra-resources'}
  }
  doLast{
    ...
  }
}

Кроме того, он использует синтаксис groovy, который дает гораздо больше возможностей для выражений, чем xml ant/maven.

Это надмножество Ant — вы можете использовать все задачи Ant в gradle с более приятным, похожим на groovy синтаксисом, т.е.

ant.copy(file:'a.txt', toDir:"xyz")

or

ant.with{
  delete "x.txt"
  mkdir "abc"
  copy file:"a.txt", toDir: "abc"
}

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

С Gradle вы можете иметь гибкость Ant и строить по соглашению Maven. Например, легко расширить обычный жизненный цикл сборки своей задачей. И вас не заставляют использовать соглашение, если вы этого не хотите. Groovy кодировать гораздо приятнее, чем XML. В Gradle вы можете определять зависимости между проектами в локальной файловой системе без необходимости публиковать артефакты для каждого в репозиторий. Наконец, Gradle использует Ivy, поэтому у него отличное управление зависимостями. Единственным реальным недостатком для меня на данный момент является отсутствие зрелой интеграции с Eclipse, но варианты для Maven на самом деле не намного лучше.

Это не мой ответ, но он определенно находит во мне отклик. Это из Technology Radar от ThinkWorks за октябрь 2012 г.:

Две вещи вызывают усталость от инструментов сборки на основе XML, таких как Ant и Maven: слишком много раздражающих остроконечных скобок и грубость подключаемых архитектур. В то время как проблемы синтаксиса могут быть решены путем генерации, архитектура подключаемых модулей серьезно ограничивает возможности инструментов сборки для плавного роста по мере усложнения проектов. Мы пришли к выводу, что плагины — это неправильный уровень абстракции, и вместо этого предпочитаем языковые инструменты, такие как Gradle и Rake, потому что они предлагают более детализированные абстракции и большую гибкость в долгосрочной перспективе.

Gradle вернул удовольствие от создания/сборки программного обеспечения. Я использовал ant для создания программного обеспечения на протяжении всей своей карьеры, и я всегда считал фактическую «сборку» частью работы разработчика неизбежным злом. Несколько месяцев назад наша компания устала от того, что не использует бинарные репозитории (т. е. регистрацию jar-файлов в vcs), и мне поручили исследовать это. Начал с плюща, так как его можно было прикрутить поверх муравья, мне не очень повезло с публикацией моих построенных артефактов, как я хотел. Я выбрал maven и взломал xml, отлично работал с некоторыми простыми вспомогательными библиотеками, но столкнулся с серьезными проблемами, пытаясь собрать приложения, готовые к развертыванию. Довольно долго я гуглил плагины и читал форумы и в итоге загрузил триллионы банок поддержки для различных плагинов, которые мне было трудно использовать. Наконец, я пошел на град (в этот момент я стал довольно горьким и раздраженным тем, что «это не должно быть НАСТОЛЬКО сложно!»)

Но с первого дня мое настроение начало улучшаться. Я куда-то шел. Мне потребовалось около двух часов, чтобы перенести мой первый модуль ant, а в файле сборки практически ничего не было. Легко устанавливается один экран. Большое «вау» было: создавать скрипты в XML, насколько это глупо? тот факт, что объявление одной зависимости занимает ОДНУ строку, меня очень привлекает -> вы можете легко увидеть все зависимости для определенного проекта на одной странице. С тех пор я был в постоянном движении, для каждой проблемы, с которой я сталкивался до сих пор, находилось простое и элегантное решение. Думаю причины следующие:

• groovy is very intuitive for java developers
• documentation is great to awesome
• the flexibility is endless

Теперь я целыми днями пытаюсь придумать новые функции, которые можно добавить в процесс сборки. Насколько это больно?

Также гораздо проще управлять нативными сборками. Ant и Maven фактически предназначены только для Java. Для Maven существуют некоторые плагины, которые пытаются работать с некоторыми нативными проектами, но они не работают эффективно. Можно написать задачи Ant, которые компилируют нативные проекты, но они слишком сложны и неудобны.

Мы делаем Java с JNI и многими другими нативными битами. Gradle значительно упростил наш беспорядок с Ant. Когда мы начали вводить управление зависимостями в нативные проекты, это было беспорядочно. Мы заставили Maven сделать это, но эквивалентный код Gradle был лишь крошечной частью того, что требовалось в Maven, и люди могли читать и понимать его, не становясь гуру Maven.

Я частично согласен с Эдом Стаубом. Gradle определенно более мощный по сравнению с maven и обеспечивает большую гибкость в долгосрочной перспективе.

Выполнив оценку перехода с maven на gradle, мы решили придерживаться самого maven из-за двух проблем, с которыми мы столкнулись с gradle (скорость ниже, чем у maven, прокси не работал).