Ant vs Maven?

Mamy teraz w firmie pisać nowy projekt i niemieccy architekci dyskutują o tym co lepsze ant czy maven.
Całe życie pracowali w ant, ale chcieli coś troche nowszego i biorą pod uwagę mavena.
Jak przekonać ich do mavena?

Przecież to nie są nawet rzeczy zbliżone do siebie. To jakby dyskutować czy kupić motocykl czy koło.

Oooooooo trafiłeś na tych legendarnych niemieckich architektów :D

Serio, to nie wiem czy bym przekonał. Nienawidzę wszystkich systemów budowania po równo:

• ant,
• maven,
• gradle

każdy, po dłuższym użyciu zaczyna wyglądać na bagno.
Przy czym i w mavenie i w gradle - problem to pluginy (do niedawna nie doceniałem potegi spie...lenia pluginów gradlowych i myślałem, że to głównie mavena problem).
Anta juz prawie zapomniałem. Plusem było to, że jednak pluginy, to były taski pojedyncze i dużo napsuć nie mogły - minusem - totalna prymitywnośc tego systemu, każdy build to osobne dzieło sztuki. Czasem trudniejsze do zrozumienia niż projekt, który był budowany.

Jakby ktoś myślał, że ciepło patrzę na Sbt lub webpack - nie zdążyłem się z nimi zaprzyjaźnić na większą skalę.

jarekr000000 napisał(a):

Serio, to nie wiem czy bym przekonał. Nienawidzę wszystkich systemów budowania po równo:

• ant,
• maven,
• gradle

każdy, po dłuższym użyciu zaczyna wyglądać na bagno.
Przy czym i w mavenie i w gradle - problem to pluginy (do niedawna nie doceniałem potegi spie...lenia pluginów gradlowych i myślałem, że to głównie mavena problem).
Anta juz prawie zapomniałem. Plusem było to, że jednak pluginy, to były taski pojedyncze i dużo napsuć nie mogły - minusem - totalna prymitywnośc tego systemu, każdy build to osobne dzieło sztuki. Czasem trudniejsze do zrozumienia niż projekt, który był bydowany.

No to jak budować wgl projekt poprawnie?

nowyworek napisał(a):

No to jak budować wgl projekt poprawnie?

I to jest bardzo dobre pytanie. Nie znam odpowiedzi na nie. Ja używam ostatnio głównie gradle. Ale serio - często nie mam pojęcia co robię i dlaczego po zamianie dwóch linijek działa...
Co gorsza, nie jestem tej wiedzy w stanie ogarnąć - kiedyś można było przeczytać książkę (np. o mavenie) i coś człowiek wiedział.
Teraz zanim przebrnę przez połowę guide - to gradle ma już dwie nowe niekompatybilne wersje, a projekty migrują sie z groovy na .kts...

Co do mavena to największy problem - to powolność i mała elastyczność (jak zaczniesz robić projekty z udziałem js/ kotlina czy czegoś tam - to zrobienie efektywnej współpracy ze środowiskiem nodejs z mavena jest chyba niemożliwe).
Do tego raz na rok potrzebujesz zrobić coś nietypowego. Wtedy się zwykle okazuje, że owszem, na to nietypowe w buildzie jest plugin do mavena. Odpalasz plugin i dostajesz NullPointerException gdzieś z kodu pluginu, nawet nie ma źródeł. Gratulacje - właśnie zawitałeś do piekła.

Ja uważam że najmniejsze zło to maven. Zwykle masz tylko dependency management i może jeden plugin to budowania i tyle. I wszystko jest przynajmniej stabilne.
Gradle to rak over9000, non stop jakieś niekompatybilne zmiany robią i musisz potem szukać np. wersji pluginów pod konkretnego gradla. I jeszcze pozwala pisać "kod" w buildfile, więc zawsze znajdzie się jakis geniusz który to zrobi...

jarekr000000 napisał(a):

Przy czym i w mavenie i w gradle - problem to pluginy (do niedawna nie doceniałem potegi spie...lenia pluginów gradlowych i myślałem, że to głównie mavena problem).
[...] Ja używam ostatnio głównie gradle. Ale serio - często nie mam pojęcia co robię i dlaczego po zamianie dwóch linijek działa...

Ostatnio podbijaliśmy w projekcie Kotlina z 1.3 do 1.4.

Wszystko się sypie, cuda nie widy, mamy kilka tych pluginów, nagle się okazuje że Kotlin plugin się wysypuje, mimo że tak naprawdę błąd leci z kompletnie innego, w tym przypadku - z reckon, któremu nagle zaczęło brakować jakiegoś property, albo coś mu się w skrypcie przestało podobać. No normalnie nie wiadomo, co się dzieje.

Rozwiązanie? Pozamieniać kolejność pluginów w plugins do skutku.

Gradle byłby niezły... gdyby taski i inne struktury buildu były niemutowalne.
Wtedy byłoby o wiele łatwiej dowiedzieć się skąd się różne problemy wzięły.

W tym kierunku idzie sbt - używany przez scalowców.
W sbt dużo struktur w buildzie jest niemutowalnych, a składnia jest taka, że wręcz uwypukla, że coś nadpisujesz zmieniasz (np. przez :=).
Problem sbt to jednak - słaba i nieaktualna często dokumentacja (chyba gorzej niż w gradle). Ostatnia książka sbt in action jest z 2015 i niestety trochę sie zmieniło.
No i wiem, że moje relatywnie pozytywne nastawienie do sbt wynika z tego, że używałem w małych prostych projektach i nie zdążyłem wdepnąć.

Tu krytyka:
https://www.lihaoyi.com/post/SowhatswrongwithSBT.html

U mnie w projekcie python + angular + react + go + javki wszystko budujemy antem.

Jestem z niego chyba najbardziej zadowolony, potem z gulpa.

• dostarcza fajny zestaw narzędzi, z których wciąż mi się wygodniej korzysta niż z basha
• można odpalać skrypty python / bash z niego, więc co bardziej skomplikowane operacje można zakodzić w czymś normalnym, lub napisać joby antowe w javie
• wymaga jednak po jakimś etapie skomplikowania narysowania mini wykresu co w jakiej kolejności jest odpalane
• wymaga potraktowania skryptów budujących jak pisanie normalnego kodu - review, pisanie bibliotek, głównej aplikacji budującej itp
• tykanie czegokolwiek spod szyldu maven / gradle to bleh,
• webpack i pochodne to też taka czarna magia, za dużo abstrakcji i przy dużej ilości narzędzi / języków ciężko się połapać w automagicznych narzędziach

Jak jest dużo rzeczy w projekcie nie da się ukryć, ant i ant contrib to proste narzędzia, prawie, że nakładki na basha - ale łatwo w to wejść i jest tego bardzo duża zaleta

jarekr000000 napisał(a):

Serio, to nie wiem czy bym przekonał. Nienawidzę wszystkich systemów budowania po równo:

• ant,
• maven,
• gradle

Ok, ale jak się nie robi magii w projekcie (pół systemu napisane w Javie, pół w Kotlinie, pół w Scali, za nadmiar połówek przepraszam) tylko wszystko jest w jednym prawilnym języku to maven wydaje się najlepszy. Jak chce się robić rzeczy nietypowe to chyba gradle lepszy bo tam łatwiej pisać wtyczki. Ale tylko raz miałem potrzebę pisania wtyczek do gradla więc ekspertem nie jestem

maven, latwo wdrozyc, a potem zdaje sie duzo wolniej degenerowac od anta/gradle

Ostatni jakis projekt to kotlin + gradle kts (też kotlin) trochę wolniej ale spoko, dopoki nikt nie wpada na pomysly za mocnego skryptowania to jest ok.
Maven jest ok. Ogólnie żadne build toole nie są idealne, każdy skopany na swój sposob ale jakos żyć trzeba.
Ale u mnie gradle jakos dużo nie robi, bo i po co? buduje jara, puszcza testy, ewentualnie jakis coverage reports etc. Im mniej robi tym lepiej.

W fimie mamy projekty kotlinowe, golangowe, pythonowe, JSowe - w każdym używany dedykowany tool pasujący do tego środowiska. (gradle, go itself + ewentualnie make, pipfile, yarn )
Uzywanie anta, gradle, mavena do budowania tego wszystkiego brzmi jak katorga i wprowadzanie bezsensownej zależności.

Ja najbardziej lubię Gradle, aczkolwiek jakoś 2 lata temu zraziłem się do pisania skryptów w kts, wolę w Groovym.
Mam wrażenie, że odarto Kotlina z wszystkiego użytecznego gdy zrobiono z niego kts do Gradle i się nie nadaje do pisania tam.

@superdurszlak wspominał o migracji na Kotlina 1.4, z ciekawości miałeś kts czy w Groovym skrypty budujące? Bo ostatnio migrowałem i bez żadnego problemu.

Osobiście, bym bronił się przed wszystkimi z nich i używał GNU Make tak długo jak się da, jednak nie zawsze jest to możliwe (np. Android zmusił mnie do użycia Graddle, choćby do zassania zależności, tu jakoś z Mavenem mi nie wychodziło). Ale zostawię tę opcję dla siebie i wrócę do popularnych opcji.

Jak wspomniano wyżej, Ant to zupelnie inna liga co Maven, a temu drugiemu ewentualnie może się równać tylko Graddle. Anta i Mavena nie lubię za XML, Gradle przynajmniej ma składnie, którą da się czytać i jest całkiem spoko w edycji. Też komunikaty ma bardziej zdatne do czytania. Ze wszystkimi sporo się namęczyłem, przywykłem do mavena, ale na przykład do współpracy z Android SDK nie chciał się namówić . Nie lubię żadnego z nich. :p

Można użyć Mavena do zarządzania zależnościami, a bardziej skomplikowaną logikę przenieść do pipeline'a CI np. Jenkins lub GitLab CI.

Przynajmniej w nowych projektach działa dobrze

Krzysztof Wilk napisał(a):

Można użyć Mavena do zarządzania zależnościami, a bardziej skomplikowaną logikę przenieść do pipeline'a CI np. Jenkins lub GitLab CI.

Przynajmniej w nowych projektach działa dobrze

Dopóki masz pipeline as code i wszystko jest i tak w VCS to można, ale jak skomplikowana logika będzie dyndała w lokalnej czasoprzestrzeni to tylko patrzeć, jak ktoś gmerając w tym CI przypadkiem rozwali budowanie aplikacji, w dodatku nie swojej :P

Ja lubię gradle

Ja lubię mavena

A nie macie wrażenia, że to wszystko zrobiło się dość opasłe? Proponuję stworzyć czysty projekt w Android Studio, zbudować go a potem sprawdzić ile plików na dysku powstało.

Meini napisał(a):

a potem sprawdzić ile plików na dysku powstało.

Noi? Rozumiem że 100x 50kB jest bardziej opasłe niż jeden 1x 5Mb.

Ciekawym build toolem, ale niepopularnym w Polsce jest też bazel: https://www.bazel.build/