Навіщо використовувати Gradle замість Ant або Maven? [зачинено]

Що насправді отримує ще один інструмент побудови, орієнтований на Java?

Якщо ви використовуєте Gradle над іншим інструментом, чому?

Я сам не використовую Градле в гніві (тільки проект іграшок досі) [автор означає, що до цього часу він використовував Градле лише для іграшкового проекту, не те, що Градле є іграшковим проектом - див. Коментарі] , але я б сказав, що причини, які можна було б розглянути, було б через розчарування Мураха та Мейвена.

На мій досвід, мураха часто лише для запису (так, я знаю, що можна писати красиво модульні, елегантні конструкції , але факт, що більшість людей цього не робить). Для будь-яких нетривіальних проектів він стає вигинним, і потрібно дуже обережно забезпечити, щоб складні конструкції були справді портативними. Її імперативний характер може призвести до тиражування конфігурації між збірками (хоча макроси тут можуть допомогти).

Мейвен застосовує протилежний підхід і очікує, що ви повністю інтегруєтесь із життєвим циклом Мевена. Досвідчені користувачі мурашок вважають це особливо неприємним, оскільки Maven позбавляє багатьох свобод, які ви маєте у Ant. Наприклад, є блог Sonatype, який перераховує багато критики Мейвена та їх відповідей.

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

Градле обіцяє потрапити на солодке місце між Ент і Мейвен. Він використовує підхід Айві для вирішення залежності. Це дозволяє домовитися про конфігурацію, але також включає завдання Ant, як громадяни першого класу. Це також розумно дозволяє використовувати існуючі сховища Maven / Ivy.

Тож якщо ви потрапили і застрягли в будь-якій з больових точок мурашника / Мейвена, напевно, варто спробувати Градле, хоча, на мою думку, залишається зрозуміти, чи не просто ви торгуєте відомими проблемами для невідомих. Доказ пудингу є в їжі, хоча тому я б заперечував судження, поки продукт не стане трохи більш зрілим, а інші не згладять будь-які перегини (вони називають це кров'яним краєм з причини). Я все ще буду використовувати його в своїх іграшкових проектах, але завжди добре бути в курсі варіантів.

Градле можна використовувати для багатьох цілей - це набагато кращий швейцарський армійський ніж ніж Ant - але він спеціально орієнтований на багатопроектні побудови.

Перш за все, Gradle - це інструмент програмування залежності, що також означає, що це інструмент програмування. За допомогою Gradle ви можете виконати будь-яке випадкове завдання у вашому налаштуванні, і Gradle переконається, що всі оголошені залежності належним чином та своєчасно виконані. Ваш код може бути розповсюджений у багатьох каталогах у будь-якому вигляді компонування (дерево, плоскі, розкидані, ...).

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

На додаток до цих функцій програмування залежності Gradle додає функції залежності проектів та JAR шляхом інтеграції з Apache Ivy. Як ви знаєте, Айві є набагато більш потужним і набагато менш вираженим інструментом управління залежностями, ніж скажімо Мейвен.

Gradle виявляє залежності між проектами та між проектами та JAR. Gradle працює з репозиторіями Maven (завантажуйте та завантажуйте), як iBiblio одне чи власні сховища, але також підтримує та інший тип інфраструктури репозиторію, який у вас може бути.

У багатопроектних версіях Gradle одночасно адаптується і адаптується до структури та архітектури. Вам не доведеться пристосовувати свою структуру чи архітектуру до інструменту збирання, як того вимагатиме Maven.

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

Це може бути трохи суперечливим, але Gradle не приховує факту, що це повноцінна мова програмування.

Ant + ant-contrib - це, по суті, цілісна повна мова програмування, яку ніхто не хоче програмувати.

Мейвен намагається взяти протилежний підхід, намагаючись бути повністю декларативним і змушує вас писати і складати плагін, якщо вам потрібна логіка. Він також нав'язує модель проекту, яка є абсолютно негнучкою. Gradle поєднує в собі найкраще з усіх цих інструментів:

• Він дотримується конфігурації конвенції (ala 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's.

Це суперкомплект мурашки - ви можете використовувати всі завдання мурахи в градусі з приємнішим, симпатичним синтаксисом, тобто.

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

або

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

Ми використовуємо Gradle і вибрали його над Maven and Ant. Мураха дав нам повну гнучкість, а Айві надає кращий менеджмент залежностей, ніж Мейвен, але не існує великої підтримки для створення багатопроектних проектів. Ви в кінцевому підсумку робите багато кодування для підтримки багатопроектних збірок. Також мати деякі побудови за домовленістю приємно і робить сценарії побудови більш стислими. Що стосується Maven, це збирає збір за угодою занадто далеко, і налаштування вашого процесу збирання стає хакі. Також Maven просуває кожен проект, що публікує артефакт. Іноді у вас є проект, розбитий на підпроекти, але ви хочете, щоб усі підпроекти були побудовані та переоформлені разом. Насправді не те, для чого призначений Maven.

З Gradle ви можете мати гнучкість Мурахи і будувати за умовами Мейвена. Наприклад, тривіально розширити звичайний життєвий цикл збірки власним завданням. І ви не змушені використовувати конвенцію, якщо цього не хочете. Groovy набагато приємніше кодувати, ніж XML. У Gradle ви можете визначити залежності між проектами в локальній файловій системі без необхідності публікувати артефакти для кожного репозиторію. Нарешті, Gradle використовує Ivy, тому він має чудове управління залежністю. Єдиним реальним недоліком для мене поки що є відсутність зрілої інтеграції Eclipse, але варіанти для Мейвена насправді не кращі.

Це не моя відповідь, але це однозначно перегукується зі мною. Це з технологічного радіолокатора ThoughtWorks від жовтня 2012 року :

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

Gradle повертає задоволення до створення / складання програмного забезпечення. Я використовував мурашник для створення програмного забезпечення всю свою кар’єру, і я завжди вважав, що фактична частина "buildit" роботи з розробки є необхідним злом. Кілька місяців тому наша компанія втомилася від використання бінарного репо (він же перевірки в банках на vcs), і мені дали завдання дослідити це. Почав з плюща, оскільки його можна було зафіксувати на мурашці, не пощастило опублікувати мої побудовані артефакти, як я хотів. Я поїхав за Maven і зламав xml, працював чудово для деяких простих контурів помічників, але у мене виникли серйозні проблеми, намагаючись зібрати програми, готові до розгортання. Досить довгий час гугли плагіни та читаючи форуми і закінчуючи завантаження триліонів банок для підтримки різних плагінів, якими я важко користувався.

Але з першого дня мій настрій почав покращуватися. Я кудись добирався. Мені потрібно було дві години перенести мій перший мурашиний модуль, а файл збірки в принципі нічого. Легко встановлюється один екран. Велике "ух" було: будувати сценарії в xml, наскільки це дурно? той факт, що оголошення однієї залежності займає ОДНИЙ рядок, дуже мені подобається -> ви можете легко побачити всі залежності для певного проекту на одній сторінці. Відтоді я постійно перебуваю в рулонах, і для кожної проблеми, з якою я стикався, існує просте і елегантне рішення. Я думаю, що це причини:

• groovy дуже інтуїтивно зрозумілий для розробників Java
• документація чудово приголомшує
• гнучкість нескінченна

Зараз я провожу свої дні, намагаючись придумати нові функції, які можна додати до нашого процесу збирання. Наскільки це хворий?

Також набагато простіше керувати власними побудовами. Мураха та Мейвен фактично лише для Java. Для Maven є декілька плагінів, які намагаються впоратися з деякими власними проектами, але вони не роблять ефективної роботи. Можуть бути записані завдання мурашок, які складають місцеві проекти, але вони занадто складні та незручні.

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

Я частково згоден з Едом Стаубом. Gradle, безумовно, є більш потужним порівняно з Maven і забезпечує більшу гнучкість на тривалий термін.

Виконавши оцінку щодо переходу від Maven до Gradle, ми вирішили дотримуватися самого Maven для двох питань, з якими ми стикалися з gradle (швидкість повільніше, ніж Maven, проксі не працював).