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

StackOverflow https://stackoverflow.com/questions/1163173

Вопрос

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

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

Это было полезно?

Решение

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

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

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

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

Gradle обещает найти золотую середину между Ant и Maven.Оно использует Айвиподход к разрешению зависимостей.Он допускает соглашение по настройке, но также включает задачи 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{
    ...
  }
}

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

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

Это не мой ответ, но это определенно находит отклик у меня.Это от Технологический радар ThoughtWorks от октября 2012 года:

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

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

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

  • groovy очень интуитивно понятен для разработчиков Java.
  • документация отличная или потрясающая
  • гибкость безгранична

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top