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

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

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

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.

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.

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ć.

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"
}

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.

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.

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?

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.

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).