Зачем использовать Gradle вместо Ant или Maven? [закрытый]

Что мне дает другой инструмент сборки, предназначенный для Java?

Если вы используете Gradle над другим инструментом, почему?

9 ответов


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

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

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

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

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

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


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

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

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

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

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

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

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


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

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

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

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

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


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

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

построить.Gradle в:

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

кроме того, он использует Groovy синтаксис, который дает гораздо больше мощности выражения, чем в XML-муравей/Мэйвен по.

это суперсет Ant-вы можете использовать все задачи Ant в gradle с более приятным, заводным синтаксисом, т. е.

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 вы можете иметь гибкость Муравья и строить по соглашению Maven. Например, тривиально расширять обычный жизненный цикл сборки с помощью собственной задачи. И вы не обязаны использовать конвенцию, если не хотите. Groovy намного приятнее для кода, чем XML. В Gradle, вы можете определить зависимости между проектами в локальной файловой системе без необходимости публикации артефактов для каждого из них в репозитории. Наконец, Gradle использует Ivy, поэтому он имеет отличное управление зависимостями. Единственным реальным недостатком для меня до сих пор является отсутствие зрелой интеграции Eclipse, но варианты Maven не намного лучше.


Это не мой ответ, но это определенно резонирует со мной. Это от Thoughtworksбыл' с октября 2012:

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


Gradle положил потеху назад в здание/собирая програмное обеспечение. Я использовал ant для создания программного обеспечения всю свою карьеру, и я всегда считал фактическую часть "buildit" работы dev необходимым злом. Несколько месяцев назад наша компания устала не использовать двоичное РЕПО (он же проверка банок в vcs), и мне дали задание исследовать это. Начал с Айви, так как ее можно было закрепить на муравье, не очень повезло с публикацией моих построенных артефактов, как я хотел. Я пошел для maven и взломан с xml, работал великолепно для некоторых простых вспомогательных библиотек, но я столкнулся с серьезными проблемами, пытаясь связать приложения, готовые к развертыванию. Довольно долго возился с плагинами и читал форумы и в итоге загрузил триллионы банок поддержки для различных плагинов, которые мне было трудно использовать. Наконец я пошел за грэдлом (в этот момент мне стало горько и досадно, что "это не должно быть так сложно!")

но с первого дня мое настроение начало улучшаться. Я был уже где-то. Мне потребовалось два часа, чтобы перенести мой первый модуль ant, и файл сборки был в основном ничем. Легко приспосабливать один экран. Большим " вау " было: build скрипты в xml, насколько это глупо? тот факт, что объявление одной зависимости занимает одну строку, очень привлекателен для меня -> вы можете легко увидеть все зависимости для определенного проекта на одной странице. С тех пор я был в постоянном движении, для каждой проблемы, с которой я сталкивался до сих пор, есть простое и элегантное решение. Я думаю, это есть причины:

  • groovy очень интуитивно понятен для разработчиков java
  • документация отлично подходит для awesome
  • гибкость бесконечен

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


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

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


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

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