Dlaczego warto korzystać z Gradle zamiast Ant lub Maven? [Zamknięte]

324

Co tak naprawdę robi mi inne narzędzie do kompilacji przeznaczone dla Javy?

Jeśli używasz Gradle na innym narzędziu, dlaczego?

ItdayD
źródło
6
Google włączył się z Gradle na Androida SDK. developers.google.com/events/io/sessions/325236644 . Intellij dodał teraz obsługę gradle. To umieszcza grad w głównym strumieniu (nie tylko projekty zabawek)
Jayan
Wiosenne artefakty są teraz również tworzone przez Gradle, myślę, że Hibernacja jest taka sama.
Amir Pashazadeh,

Odpowiedzi:

248

Nie używam Gradle w gniewie (jak dotąd projekt zabawkowy) [autor oznacza, że ​​używał Gradle tylko do tej pory projektu zabawkowego, nie że Gradle to projekt zabawkowy - patrz komentarze] , ale powiedziałbym, że powodem, dla którego warto by go rozważyć, były frustracje Anta i Mavena.

Z mojego doświadczenia wynika, że ​​Ant jest często tylko do zapisu (tak, wiem, że można pisać pięknie modularne, eleganckie wersje , ale faktem jest, że większość ludzi tego nie robi). W przypadku wszelkich nietrywialnych projektów robi się oszałamiający i dokłada wszelkich starań, aby złożone kompilacje były naprawdę przenośne. Jego bezwzględny charakter może prowadzić do replikacji konfiguracji między kompilacjami (chociaż makra mogą tutaj pomóc).

Maven przyjmuje odwrotne podejście i oczekuje, że całkowicie zintegrujesz się z cyklem życia Maven. Doświadczeni użytkownicy Anta uważają to za szczególnie denerwujące, ponieważ Maven usuwa wiele swobód, które masz w Ant. Na przykład istnieje blog Sonatype, w którym wymieniono wiele krytyków Mavena i ich odpowiedzi.

Mechanizm wtyczek Maven pozwala na bardzo wydajne konfiguracje kompilacji, a model dziedziczenia oznacza, że ​​możesz zdefiniować mały zestaw nadrzędnych POM-ów obudowujących konfiguracje kompilacji dla całego przedsiębiorstwa, a poszczególne projekty mogą dziedziczyć te konfiguracje, pozostawiając je lekkimi. Konfiguracja Maven jest bardzo szczegółowa (choć Maven 3 obiecuje rozwiązać ten problem), a jeśli chcesz zrobić coś, co nie jest „sposobem Mavena”, musisz napisać wtyczkę lub skorzystać z włamanej integracji Anta. Uwaga: Lubię pisać wtyczki Maven, ale doceniam to, że wielu sprzeciwi się włożonemu wysiłkowi.

Gradle obiecuje trafić w słodkie miejsce między Antem a Mavenem. Wykorzystuje podejście Ivy do rozwiązywania zależności. Umożliwia konwencję nad konfiguracją, ale obejmuje również zadania Ant jako obywatele pierwszej klasy. Mądrze pozwala także korzystać z istniejących repozytoriów Maven / Ivy.

Więc jeśli trafiłeś i utknąłeś w którymś z punktów bólu Ant / Maven, prawdopodobnie warto wypróbować Gradle'a, chociaż moim zdaniem okaże się, że nie wymieniłbyś znanych problemów na nieznane. Dowodem na to, że budyń jest w jedzeniu, więc zastrzegam sobie ocenę, dopóki produkt nie stanie się trochę bardziej dojrzały, a inni wyprostują wszelkie załamania (z jakiegoś powodu nazywają to krwawiącą krawędzią). Nadal będę go używał w moich projektach zabawek. Zawsze dobrze jest znać opcje.

Bogaty sprzedawca
źródło
69
@Tom Nie mówiłem, że Gradle jest projektem zabawkowym, ale do tej pory używałem go tylko w projekcie zabawkowym. Przepraszam, że poczułeś się wprowadzony w błąd
bogaty sprzedawca,
18
Sleer - pomimo wieku edytowałem post, aby wyjaśnić to, co zostało wyjaśnione w komentarzach - nieporozumienie natychmiast koloruje post jako anty-Gradle. Jeśli ktoś badający Gradle'a (tak jak ja) początkowo źle rozumie to zdanie otwierające (tak jak ja), może nie czytać dużo dalej lub czytać wyjaśniającego komentarza (jak prawie ja). Cofnij / edytuj moją zmianę, jeśli się nie zgadzasz / nie lubisz.
Bert F
48
Z tego, co jest warte, nie odniosłem wrażenia, że ​​@RichSeller miał na myśli, że Gradle był w ogóle dla projektów zabawkowych (nawet przed przeczytaniem części w nawiasach kwadratowych).
Jack Leow
2
Kiedy czytałem „tylko projekt zabawkowy do tej pory”, odniosłem wrażenie, że autor miał na myśli, że sam Gradle jest projektem zabawkowym, szczególnie po mylącym „Nie używam Gradle w gniewie”. Sugeruje to, że autor używa Gradle, gdy nie jest zły. Proponuję po prostu przepisać pierwsze całe zdanie.
osa
79

Gradle może być używany do wielu celów - to znacznie lepszy szwajcarski scyzoryk niż Ant - ale jest szczególnie skoncentrowany na kompilacjach z wieloma projektami.

Przede wszystkim Gradle jest narzędziem do programowania zależności, co oznacza również, że jest to narzędzie do programowania. Dzięki Gradle możesz wykonać dowolne losowe zadanie w swojej konfiguracji, a Gradle upewni się, że wszystkie zadeklarowane zależności są poprawnie i terminowo wykonane. Twój kod może być rozłożony na wiele katalogów w dowolnym układzie (drzewo, płaski, rozproszony, ...).

Gradle ma dwie odrębne fazy: ocenę i wykonanie. Zasadniczo podczas oceny Gradle będzie szukał i oceniał skrypty budowania w katalogach, w których powinien wyglądać. Podczas wykonywania Gradle wykona zadania, które zostały załadowane podczas oceny, biorąc pod uwagę wzajemne zależności zadań.

Oprócz tych funkcji programowania zależności Gradle dodaje funkcje zależności projektu i JAR poprzez integrację z Apache Ivy. Jak wiesz, Ivy jest o wiele potężniejszym i znacznie mniej opiniotwórczym narzędziem do zarządzania zależnościami niż powiedzą Maven.

Gradle wykrywa zależności między projektami oraz między projektami a plikami JAR. Gradle współpracuje z repozytoriami Maven (pobieranie i przesyłanie), takimi jak jedno i własne repozytoria iBiblio, ale także obsługuje i inną infrastrukturę repozytorium, którą możesz mieć.

W kompilacjach z wieloma projektami Gradle jest zarówno przystosowalny, jak i dostosowuje się do struktury i architektury kompilacji. Nie musisz dostosowywać swojej struktury ani architektury do narzędzia do budowania, jak byłoby to wymagane w Maven.

Gradle bardzo stara się nie wchodzić ci w drogę, wysiłek, którego Maven prawie nigdy nie podejmuje. Konwencja jest dobra, ale także elastyczność. Gradle oferuje o wiele więcej funkcji niż Maven, ale co najważniejsze w wielu przypadkach Gradle oferuje bezbolesną ścieżkę przejścia od Maven.

Steven Devijver
źródło
64

Może to być nieco kontrowersyjne, ale Gradle nie ukrywa faktu, że jest to w pełni rozwinięty język programowania.

Ant + ant-contrib jest zasadniczo kompletnym językiem programowania, w którym nikt tak naprawdę nie chce się programować.

Maven próbuje zastosować odwrotne podejście, starając się być całkowicie deklaratywnym i zmuszając cię do napisania i skompilowania wtyczki, jeśli potrzebujesz logiki. Nakłada również całkowicie nieelastyczny model projektu. Gradle łączy najlepsze z tych wszystkich narzędzi:

  • Jest zgodny z konwencją nad konfiguracją (ala Maven), ale tylko w takim zakresie, w jakim chcesz
  • Pozwala pisać elastyczne niestandardowe zadania, takie jak w Ant
  • Zapewnia obsługę wielu modułów projektu, która jest lepsza niż zarówno Ant, jak i Maven
  • Ma DSL, który sprawia, że ​​80% rzeczy jest łatwe, a 20% rzeczy możliwe (w przeciwieństwie do innych narzędzi do budowania, które sprawiają, że 80% jest łatwe, 10% możliwe, a 10% efektywnie niemożliwe).

Gradle jest najbardziej konfigurowalnym i elastycznym narzędziem do budowania, z którego jeszcze nie korzystałem. Nauczenie się DSL i koncepcji takich jak konfiguracje wymaga wcześniejszych inwestycji, ale jeśli potrzebujesz bezsensownego i całkowicie konfigurowalnego narzędzia do budowania JVM, trudno go pokonać.

omnisis
źródło
49

Gradle ładnie łączy Ant i Maven, czerpiąc to, co najlepsze z obu ram. Elastyczność z Ant i konwencji w zakresie konfiguracji, zarządzania zależnościami i wtyczek z Maven.

Więc jeśli chcesz mieć standardową kompilację Java, jak w maven, ale zadanie testowe musi wykonać jakiś niestandardowy krok, może wyglądać jak poniżej.

build.gradle:

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

Ponadto używa groovy składni, która daje znacznie więcej mocy ekspresji niż xml ant / maven.

Jest to nadzbiór Anta - możesz używać wszystkich zadań Ant w gradiencie z ładniejszą, groovy składnią, tj.

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

lub

ant.with{
  delete "x.txt"
  mkdir "abc"
  copy file:"a.txt", toDir: "abc"
}
piotrga
źródło
35

Używamy Gradle i wybraliśmy go spośród Maven i Ant. Ant dał nam całkowitą elastyczność, a Ivy zapewnia lepsze zarządzanie zależnościami niż Maven, ale nie ma wielkiego wsparcia dla kompilacji z wieloma projektami. W końcu robisz dużo kodowania, aby wspierać kompilacje z wieloma projektami. Również kompilacja według konwencji jest przyjemna i sprawia, że ​​skrypty kompilacji są bardziej zwięzłe. W przypadku Maven kompilacja przebiega zbyt daleko, a dostosowywanie procesu kompilacji staje się włamaniem. Ponadto Maven promuje każdy projekt publikujący artefakt. Czasami masz projekt podzielony na podprojekty, ale chcesz, aby wszystkie podprojekty były budowane i wersjonowane razem. Naprawdę nie jest to coś, do czego zaprojektowano Maven.

Dzięki Gradle możesz mieć elastyczność Anta i budować zgodnie z konwencją Maven. Na przykład wydłużenie tradycyjnego cyklu życia kompilacji o własne zadanie jest banalne. I nie musisz zmuszać się do korzystania z konwencji, jeśli nie chcesz. Groovy jest o wiele ładniejszy do kodowania niż XML. W Gradle można zdefiniować zależności między projektami w lokalnym systemie plików bez potrzeby publikowania artefaktów dla każdego z nich w repozytorium. Wreszcie, Gradle używa Ivy, więc ma doskonałe zarządzanie zależnościami. Jedynym prawdziwym minusem dla mnie jest brak dojrzałej integracji Eclipse, ale opcje Maven nie są naprawdę lepsze.

BCK
źródło
2
Osobiście uważam, że integracja z Eclipse jest w porządku. Instalacja go w Juno jest dość prosta.
djangofan,
1
2 lata po tym, jak autor napisał tę odpowiedź!
Dennis
21

To nie jest moja odpowiedź, ale zdecydowanie rezonuje ze mną. Pochodzi z radaru technologicznego ThoughtWorks z października 2012 r . :

Dwie rzeczy spowodowały zmęczenie narzędziami do budowania opartymi na XML, takimi jak Ant i Maven: zbyt wiele wściekłych spiczastych nawiasów klamrowych i szorstkość architektur wtyczek. Podczas gdy problemy ze składnią można rozwiązywać przez generowanie, architektury wtyczek poważnie ograniczają zdolność do tworzenia narzędzi do tworzenia z wdziękiem, gdy projekty stają się bardziej złożone. Doszliśmy do wniosku, że wtyczki są niewłaściwym poziomem abstrakcji i wolimy zamiast tego narzędzia oparte na języku, takie jak Gradle i Rake, ponieważ oferują one bardziej szczegółowe abstrakty i większą elastyczność w dłuższej perspektywie.

Ed Staub
źródło
16

Gradle przywrócił zabawę do oprogramowania do budowania / montażu. Przez całą swoją karierę tworzyłem oprogramowanie i zawsze uważałem, że faktyczna część „buildit” pracy deweloperów jest złem koniecznym. Kilka miesięcy temu nasza firma zmęczyła się nieużywaniem binarnego repozytorium (czyli sprawdzania słoików w vcs) i otrzymałem zadanie zbadania tego. Zaczęło się od bluszczu, ponieważ można go było przykręcić do mrówki, nie miałem szczęścia publikować moich zbudowanych artefaktów tak, jak chciałem. Poszedłem do raju i zhackowałem xml, działałem wspaniale dla prostych bibliotek pomocniczych, ale miałem poważne problemy z pakowaniem aplikacji gotowych do wdrożenia. Od dłuższego czasu miałem problemy z przeglądaniem wtyczek i czytaniem forów, a skończyło się na pobieraniu bilionów słoików wsparcia dla różnych wtyczek, z których miałem trudności.

Ale od pierwszego dnia mój nastrój zaczął się poprawiać. Gdzieś się dostawałem. Migracja pierwszego modułu mrówki zajęła mi dwie godziny, a plik kompilacji był w zasadzie niczym. Łatwo dopasowany jeden ekran. Wielkie „wow” brzmiało: buduj skrypty w xml, jakie to głupie? fakt, że zadeklarowanie jednej zależności zajmuje JEDEN wiersz, jest dla mnie bardzo pociągający -> możesz łatwo zobaczyć wszystkie zależności dla określonego projektu na jednej stronie. Od tego czasu jestem na bieżąco, na każdy problem, z którym się spotkałem, jest proste i eleganckie rozwiązanie. Myślę, że są to powody:

  • groovy jest bardzo intuicyjny dla programistów Java
  • dokumentacja jest świetna do niesamowitej
  • elastyczność jest nieograniczona

Teraz spędzam dni, próbując wymyślić nowe funkcje, które można dodać do naszego procesu kompilacji. Jak bardzo to jest chore?

Kalle
źródło
+1 za „budowanie skryptów w XML, jakie to głupie?” W 2000 r. XML był uważany za najfajniejszą rzecz na świecie, więc szczerze mówiąc, wydawał się wtedy bardziej modny niż głupi. Języki programowania oparte na XML są w zasadzie wypaczone, ponieważ mają ograniczniki otwarcia / zamknięcia dla każdej komendy. Ale są to bardzo szczegółowe wersje lisp, w których 4 znaki kodu stają się 40 znakami. To jeden ze sposobów nauki pisania, ale nie moja filiżanka herbaty.
GlenPeterson
8

Znacznie łatwiej jest również zarządzać kompilacjami natywnymi. Ant i Maven działają wyłącznie w Javie. Istnieją pewne wtyczki dla Maven, które próbują obsłużyć niektóre rodzime projekty, ale nie wykonują skutecznej pracy. Można napisać zadania Ant, które kompilują natywne projekty, ale są one zbyt złożone i niewygodne.

Robimy Javę z JNI i wieloma innymi natywnymi bitami. Gradle znacznie uprościł nasz bałagan z mrówkami. Kiedy zaczęliśmy wprowadzać zarządzanie zależnościami do rodzimych projektów, było bałagan. Zmusiliśmy Maven do zrobienia tego, ale równoważny kod Gradle stanowił niewielki ułamek tego, co było potrzebne w Maven, a ludzie mogli go przeczytać i zrozumieć, nie stając się guru Maven.

swpalmer
źródło
3

Częściowo zgadzam się z Edem Staubem. Gradle jest zdecydowanie silniejszy w porównaniu do maven i zapewnia większą elastyczność na dłuższą metę.

Po przeprowadzeniu oceny przejścia z maven na grad, postanowiliśmy trzymać się samego maven z powodu dwóch problemów, które napotkaliśmy z gradem (prędkość jest mniejsza niż maven, proxy nie działało).

zyje
źródło
Miałem problemy z serwerem proxy w wersji 1.2, ale od tego czasu myślę, że działało. Tak bardzo, ctnlm lub taka aplikacja jest rozwiązaniem dla maven, aby rozwiązać problemy z proxy NTLM. Gradle ma to wsparcie po wyjęciu z pudełka. chociaż jest to tak trywialne, zastanawiam się, dlaczego Maven nigdy nie miał takiej obsługi od razu dla serwerów proxy opartych na uwierzytelnianiu NTLM.
skipy