Почему использование Gradle вместо Муравья или Знатока? [закрытый]

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

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

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

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

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

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

Gradle очень старается не мешать вам, а Maven почти никогда не делает этого. Согласованность - это хорошо, но гибкость тоже.

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{
    ...
  }
}

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

Это расширенный набор Ant - вы можете использовать все задачи Ant в Gradle с более приятным синтаксисом, похожим на Groovy, т.е.

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

или

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 на самом деле не намного лучше.