Ant vs Maven?

1

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?

1

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

11

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

2

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

0
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?

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

2

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

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

1

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

3

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

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0