Dlaczego Maven ma tak złą reputację? [Zamknięte]

W Internecie dużo się mówi o tym, jak zły jest Maven. Od kilku lat korzystam z niektórych funkcji Mavena i moim zdaniem najważniejszą korzyścią jest zarządzanie zależnościami.

Dokumentacja Mavena jest mniej niż wystarczająca, ale generalnie, gdy muszę coś zrobić, raz to wymyślam i wtedy działa (na przykład, gdy zaimplementowałem podpisywanie słoików). Nie sądzę, że Maven jest świetny, ale rozwiązuje pewne problemy, bez których byłby prawdziwy ból.

Dlaczego więc Maven ma tak złą reputację i jakich problemów z Maven mogę się spodziewać w przyszłości? Może są o wiele lepsze alternatywy, o których nie wiem? (Na przykład nigdy nie przyglądałem się szczegółowo Ivy).

UWAGA: To nie jest próba wywołania kłótni. To próba wyczyszczenia FUD.

Zajrzałem do mavena jakieś sześć miesięcy temu. Rozpoczynaliśmy nowy projekt i nie mieliśmy żadnej spuścizny do wsparcia. To mówi:

• Maven to wszystko albo nic. A przynajmniej na tyle, na ile mogłem stwierdzić z dokumentacji. Nie można łatwo używać mavena jako zamiennika mrówki i stopniowo przyjmować bardziej zaawansowane funkcje.
• Zgodnie z dokumentacją Maven to transcendentalne szczęście, które spełnia wszystkie Twoje najśmielsze marzenia. Musisz tylko medytować nad podręcznikiem przez 10 lat, zanim osiągniesz oświecenie.
• Maven uzależnia proces budowania od połączenia sieciowego.
• Maven ma bezużyteczne komunikaty o błędach. Porównaj „Target x nie istnieje w projekcie y” z „Nieprawidłowe zadanie 'uruchomione' mvn: musisz określić prawidłową fazę cyklu życia lub cel w formacie plugin: goal lub pluginGroupId: pluginArtifactId: pluginVersion: goal" Pomocnie, sugeruje to uruchomienie mvn z -e, aby uzyskać więcej informacji, co oznacza, że ​​wydrukuje ten sam komunikat, a następnie ślad stosu dla wyjątku BuildFailureException.

Dużą część mojej niechęci do mavena można wyjaśnić następującym fragmentem z Better Builds with Maven:

Gdy ktoś chce wiedzieć, czym jest Maven, zwykle zapyta „Czym właściwie jest Maven?” I oczekuje krótkiej, dosadnej odpowiedzi. „Cóż, to narzędzie do budowania lub framework do tworzenia skryptów” Maven to więcej niż trzy nudne, mało inspirujące słowa. Jest to połączenie pomysłów, standardów i oprogramowania, a definicji Mavena nie da się wydestylować do po prostu przetrawionych dźwięków. Rewolucyjne idee są często trudne do przekazania słowami.

Moja sugestia: jeśli nie możesz przekazać idei słowami, nie powinieneś próbować pisać książki na ten temat, ponieważ nie zamierzam telepatycznie wchłaniać pomysłów.

• Od samego początku narzuca ci sztywną strukturę.
• Jest oparty na XML, więc jest tak trudny do odczytania, jak ANT.
• Raportowanie błędów jest niejasne i pozostawia Cię na lodzie, gdy coś pójdzie nie tak.
• Dokumentacja jest słaba.
• To sprawia, że ​​trudne rzeczy stają się łatwe, a proste trudne.
• Utrzymanie środowiska kompilacji Mavena zajmuje zbyt dużo czasu, co jest sprzeczne z sensem posiadania śpiewającego systemu kompilacji.
• Zrozumienie, że znalazłeś błąd w maven i nie skonfigurowałeś czegoś źle, zajmuje dużo czasu. A błędy istnieją i to w zaskakujących miejscach.
• Wiele obiecuje, ale zdradza jak piękną i uwodzicielską, ale emocjonalnie zimną i manipulującą kochanką.

Z pewnością narzekałem i narzekałem na maven w przeszłości. Ale teraz nie byłbym bez tego. Czuję, że korzyści znacznie przewyższają wszelkie problemy. Głównie:

• Standaryzowana struktura projektu.
  • Biorąc pod uwagę nowy deweloper dołączający do projektu:
    • Kiedy mówisz, że jest to projekt Maven, programista zna układ projektu oraz jak skompilować i spakować projekt
    • Kiedy mówisz, że jest to projekt Ant, programista będzie musiał poczekać, aż wyjaśnisz więcej, lub będzie musiał przejść przez plik build.xml, aby dowiedzieć się, co zrobić.
  • Oczywiście z Antem zawsze można narzucić standard całej firmy, ale myślę, że częściej niż nie, to przysłowiowe koło będzie można wymyślać na nowo.
• Zarządzanie zależnościami.
  • Nie tylko z zewnętrznymi bibliotekami, ale także z wewnętrznymi bibliotekami / modułami. Upewnij się, że używasz serwera proxy repozytorium Maven, takiego jak Nexus lub Artifactory .
  • Można to zrobić częściowo z Ivy . W rzeczywistości, jeśli wszystko, czego potrzebujesz, to zarządzanie zależnościami, prawdopodobnie lepiej będzie korzystać z Ivy.
• Szczególnie w ramach projektu. Zauważyłem, że bardzo przydatne jest odbijanie małych podprojektów i maven dobrze sobie z tym radzi. Z mrówką jest znacznie trudniej.
• Standardowe zarządzanie artefaktami (szczególnie w połączeniu z nexusem lub artefaktem )
• Wtyczka wydania jest cudowna.
• Integracja Eclipse i NetBeans jest całkiem dobra.
• Integracja z Hudson jest znakomita. W szczególności wykresy trendów dla rzeczy takich jak znajdowanie błędów.
• Jest to punkt niewielkie, ale fakt, że Maven osadza szczegóły, takie jak numer wersji wewnątrz słoika lub wojny (nie tylko w nazwie pliku) domyślnie jest ogromnie pomocne.

Wady dla mnie to głównie:

• Linia poleceń nie jest pomocna. Na początku bardzo mnie to zniechęciło.
• Format XML jest bardzo rozwlekły. Rozumiem, dlaczego zostało to zrobione w ten sposób, ale nadal jest to trudne do odczytania.
  • To powiedziawszy, ma XSD do łatwej edycji w IDE.
• Na początku trudno jest się nad tym zastanowić. Na przykład cykl życia.
  • Ostateczny przewodnik po maven jest jednak dobrym wprowadzeniem.

Naprawdę wierzę, że warto poświęcić trochę czasu na poznanie mavena.

Moje praktyczne doświadczenie z dwóch dużych projektów jest takie, że poświęciliśmy 1000-1500 godzin na każdy projekt na problemy związane z maven, z wyłączeniem 500-godzinnego wysiłku związanego z przejściem z maven 1 do maven 2.

Od tego czasu muszę powiedzieć, że absolutnie nienawidzę maven. Denerwuję się, kiedy o tym myślę.

Integracja Eclipse jest okropna. (Mieliśmy niekończące się problemy z generowaniem kodu, na przykład, gdy zaćmienie nie synchronizowało się z wygenerowanym kodem i wymagało całkowitej przebudowy, dość często. Winą jest zarówno maven, jak i zaćmienie, ale zaćmienie jest bardziej przydatne niż maven i powiedzmy emacs, więc zaćmienie pozostaje i musi odejść.)

Mieliśmy wiele zależności i, jak odkryliśmy, błędy składniowe są w rzeczywistości przypisywane do publicznych repozytoriów mavenów dość często, co może zrujnować godziny Twojego cennego czasu. Co tydzień. Sposób obejścia problemu polega na posiadaniu serwera proxy lub repozytorium zarządzanego lokalnie, co również zajęło trochę czasu.

Struktura projektu Mavens nie nadaje się do programowania w Eclipse, a czas kompilacji w Eclipse wydłuża się.

W wyniku problemu z generowaniem i synchronizacją kodu musieliśmy dość często przebudowywać od podstaw, redukując cykl kodu / kompilacji / testów do niekończącego się cyklu kompilacji / websurf / uśpienia / śmierci / kodu, przenosząc Cię z powrotem do lat 90. 40 minut kompilacji.

Jedynym usprawiedliwieniem dla mavena jest rozwiązanie zależności, ale chciałbym to robić od czasu do czasu, nie w każdej kompilacji.

Podsumowując, maven jest tak daleko od KISS, jak to tylko możliwe. A rzecznicy są zazwyczaj typem ludzi, którzy świętują swoje urodziny, kiedy ich wiek jest liczbą pierwszą. Zapraszam do głosowania na mnie :-)

Maven jest świetny. Moim zdaniem powodem jego reputacji jest stroma krzywa uczenia się. (z którym w końcu jestem bliski pokonania)

Dokumentacja jest nieco trudna do przebrnięcia, po prostu dlatego, że wydaje się, że jest dużo tekstu i nowych rzeczy do zrozumienia, zanim zacznie mieć sens. Mówię, że wystarczy czasu, aby Maven stał się szerzej chwalony.

Ponieważ Maven jest narzędziem do zredukowania dorosłych mężczyzn do szlochających mas absolutnego przerażenia.

Plusy:

• Zarządzanie zależnościami. Od kilku lat moi współpracownicy i ja nie pobieramy i nie zarządzamy ręcznie zależnościami. To ogromna oszczędność czasu.
• Niezależność od IDE. Okazuje się, że wszystkie główne IDE, Eclipse, IDEA i NetBeans mają przyzwoite wsparcie dla projektów Maven, więc nasi programiści nie są zamknięci w jednym konkretnym IDE.
• Wiersz poleceń. Dzięki Maven obsługa jednoczesnych konfiguracji IDE i wiersza poleceń jest prosta, co jest dobre dla ciągłej integracji.

Cons:

• Muszę zainwestować w naukę Mavena. Cóż, muszę to zrobić. Dobra wiadomość, nie wszyscy w zespole muszą się uczyć.
• Dokumentacja. Kiedyś był problem, teraz dzięki Sonatype i ich książce ( http://www.sonatype.com/products/maven/documentation/book-defguide ) sytuacja jest znacznie lepsza.
• Sztywność. Czasami robienie rzeczy tak, jak chcesz, jest trudne i frustrujące. Radziłbym nie walczyć i nie zmuszać Mavena do robienia rzeczy, które robi najlepiej, prostych kompilacji lub gdy dostępne jest stabilne mojo. W innych przypadkach rezygnujemy i robimy coś z zadaniami Ant ( http://maven.apache.org/plugins/maven-antrun-plugin/ ) lub zewnętrznymi programami. Moim ulubionym jest wtyczka Groovy ( http://groovy.codehaus.org/GMaven ).

Konkurencja:

• Ant: nie ma zarządzania zależnościami. Kropka.
• Ivy: wciąż mniej dojrzały niż Maven (nie żeby ten drugi też nie miał swoich dziwactw). Prawie ten sam zestaw funkcji, więc nie ma ważnego powodu, aby się przenieść. Zrobiłem kilka prób, aby spróbować; wszystko nieudane.

Podsumowując: wszystkie nasze projekty są realizowane z Maven już od kilku lat.

Myślę, że ma złą opinię wśród ludzi, którzy mają najprostsze i najbardziej skomplikowane projekty.

Jeśli budujesz pojedynczą wojnę z jednej bazy kodu, zmusza to do przeniesienia struktury projektu i ręcznego umieszczenia dwóch z trzech słoików w pliku POM.

Jeśli budujesz jeden plik EAR z zestawu dziewięciu prototypów plików EAR z kombinacją pięciu plików WAR, trzech EJB i 17 innych narzędzi, plików JAR zależności i konfiguracji, które wymagają poprawiania plików MANIFEST.MF i XML w istniejących zasobach podczas ostatecznej kompilacji; wtedy Maven jest prawdopodobnie zbyt restrykcyjny. Taki projekt staje się bałaganem skomplikowanych zagnieżdżonych profili, plików właściwości i niewłaściwego wykorzystania celów kompilacji Mavena i oznaczenia klasyfikatora.

Więc jeśli jesteś w dolnych 10% krzywej złożoności, jest to przesada. W górnych 10% tej krzywej jesteś w kaftanie bezpieczeństwa.

Wzrost Mavena wynika z tego, że działa dobrze dla środkowych 80%

Moje doświadczenie jest echem frustracji wielu postów tutaj. Problem z Mavenem polega na tym, że zawija i ukrywa szczegóły zarządzania kompilacją w poszukiwaniu ostatecznej automagicznej dobroci. To sprawia, że ​​jesteś prawie bezradny, jeśli się zepsuje.

Z mojego doświadczenia wynika, że ​​każdy problem z maven szybko przerodził się w wielogodzinne polowanie na bekasy przez sieci zagnieżdżonych plików xml, w doświadczeniu podobnym do leczenia kanałowego.

Pracowałem także w sklepach, które w dużym stopniu polegały na Mavenie, ludzie, którzy go lubili (lubili go ze względu na aspekt „naciśnij przycisk, załatw wszystko”), nie rozumieli tego. Kompilacje maven miały milion automatycznych celów, co z pewnością byłoby przydatne, gdybym miał ochotę poświęcić godziny na przeczytanie, co zrobili. Lepsze 2 cele, które działają i które w pełni rozumiesz.

Uwaga: ostatnio współpracowałem z Maven 2 lata temu, teraz może być lepiej.

Podobnie jak Glenn, nie sądzę, że Maven ma złą reputację, ale mieszaną reputację. Pracuję od 6 miesięcy wyłącznie próbując przenieść dość duży projekt do Maven i wyraźnie pokazuje to ograniczenia narzędzia.

Z mojego doświadczenia wynika, że ​​Maven jest dobry do:

• zarządzanie zależnościami zewnętrznymi
• scentralizowane zarządzanie kompilacją (dziedziczenie pom)
• wiele wtyczek do wielu rzeczy
• bardzo dobra integracja z narzędziami ciągłej integracji
• bardzo dobre możliwości raportowania (FindBugs, PMD, Checkstyle, Javadoc, ...)

I ma pewne problemy z:

• podejście wszystko albo nic (trudno migrować powoli do Maven)
• zależności złożone, zależności międzymodułowe
• cykliczne zależności (wiem, zły projekt, ale nie możemy naprawić 5 lat tworzenia ...)
• spójność (zakresy wersji nie wszędzie działają tak samo)
• błędy (ponownie z zakresami wersji)
• odtwarzalne kompilacje (jeśli nie poprawisz liczby wersji wszystkich wtyczek, nie możesz być pewien, że otrzymasz tę samą kompilację w ciągu 6 miesięcy)
• brak dokumentacji (dokument jest całkiem niezły, jeśli chodzi o podstawy, ale nie ma wielu przykładów, jak radzić sobie z dużymi projektami)

Aby nadać kontekst, około 30 programistów pracuje nad tym projektem, a projekt istnieje już od ponad 5 lat, więc: wiele spuścizny, wiele już wdrożonych procesów, wiele niestandardowych, zastrzeżonych narzędzi już zostało wdrożonych. Postanowiliśmy spróbować przejść na Maven, ponieważ koszt utrzymania naszych własnych narzędzi stawał się zbyt wysoki.

Chciałbym odpierać kilka skarg zgłoszonych na tym forum:

Maven to wszystko albo nic. A przynajmniej na tyle, na ile mogłem stwierdzić z dokumentacji. Nie można łatwo używać mavena jako zamiennika mrówki i stopniowo przyjmować bardziej zaawansowane funkcje.

To nieprawda. Wielką wygraną Mavena jest używanie go do zarządzania swoimi zależnościami w racjonalny sposób, a jeśli chcesz to robić w maven i robić wszystko inne w mrówce, możesz. Oto jak:

<?xml version="1.0" encoding="UTF-8"?>
<project name="foo" basedir="." xmlns:maven="antlib:org.apache.maven.artifact.ant" >
  <maven:dependencies verbose="true" pathId="maven.classpath">
    <maven:pom id="maven.pom" file="pom.xml" />
  </maven:dependencies>
</project>

Masz teraz obiekt classpath o nazwie „maven.classpath”, który zawiera wszystkie zależności maven zdefiniowane w pliku pom. Wszystko, czego potrzebujesz, to umieścić plik jar maven mrówka z zadaniami w katalogu lib twojego programu Ant.

Maven uzależnia proces budowania od połączenia sieciowego.

Domyślny proces zależności i pobierania wtyczek zależy od połączenia sieciowego, tak, ale tylko dla początkowej kompilacji (lub jeśli zmienisz zależności lub używane wtyczki). Następnie wszystkie słoiki są buforowane lokalnie. A jeśli chcesz wymusić połączenie bez sieci, możesz powiedzieć mavenowi, aby używał trybu offline.

Od samego początku narzuca ci sztywną strukturę.

Nie jest jasne, czy odnosi się to do formatu pliku, czy do problemu „konwencja czy konfiguracja”. W tym drugim przypadku istnieje wiele niewidocznych ustawień domyślnych, takich jak oczekiwana lokalizacja plików źródłowych i zasobów Java lub zgodność źródła. Ale to nie jest sztywność, to wprowadzanie rozsądnych wartości domyślnych, więc nie musisz ich jawnie definiować. Wszystkie ustawienia można łatwo zmienić (chociaż początkującemu może być trudno znaleźć w dokumentacji sposób zmiany pewnych rzeczy).

Jeśli mówisz o formacie pliku, cóż, jest to omówione w odpowiedzi na następną część ...

Jest oparty na XML, więc jest tak trudny do odczytania, jak ANT.

Po pierwsze, nie rozumiem, jak możesz narzekać, że jakiś aspekt czegoś „nie jest lepszy od mrówki” jako usprawiedliwienie dla tego, że ma złą reputację. Po drugie, chociaż nadal jest to XML, format XML jest znacznie bardziej zdefiniowany. Ponadto, ponieważ jest tak zdefiniowany, o wiele łatwiej jest stworzyć rozsądny, gruby edytor klienta dla POM. Widziałem strony długie, skrypty budujące mrówki, które przeskakują wszędzie. Żaden edytor skryptów kompilacji Ant nie uczyni tego bardziej przyjemnym, po prostu kolejna długa lista połączonych zadań przedstawionych w nieco inny sposób.

Powiedziawszy, że jest kilka skarg, które widziałem tutaj, które mają lub miały jakąś zasadność, największa istota

• Dokumentacja jest słaba / brakuje
• Odtwarzalne kompilacje
• Integracja Eclipse jest zła
• Robaki

Na co moja odpowiedź jest dwojaka. Po pierwsze, Maven jest znacznie młodszym narzędziem niż Ant czy Make, więc musisz się spodziewać, że dojście do poziomu dojrzałości tych aplikacji zajmie trochę czasu. Po drugie, jeśli ci się to nie podoba, napraw to . Jest to projekt open source i używanie go, a następnie narzekanie na coś, w czym każdy może mieć swój udział, wydaje mi się dość głupie. Nie podoba Ci się dokumentacja? Przyczyń się do tego, aby była jaśniejsza, pełniejsza lub bardziej dostępna dla początkującego.

Problem z odtwarzalnymi kompilacjami dzieli się na dwa problemy, zakresy wersji i automatyczne aktualizacje wtyczek maven. W przypadku aktualizacji wtyczki, chyba że upewniasz się, że przebudowując projekt rok później, używasz dokładnie tego samego JDK i dokładnie tej samej wersji Ant, cóż, to jest ten sam problem z inną nazwą. W przypadku zakresów wersji zalecam pracę nad wtyczką, która utworzy tymczasowy pom z zablokowanymi wersjami dla wszystkich bezpośrednich i przechodnich zależności i uczyni go częścią cyklu życia wydania mavena. W ten sposób pomsy kompilacji wydania są zawsze dokładnymi opisami wszystkich zależności.

Zasługuje na reputację, jaką ma. Nie każdy potrzebuje sztywnej struktury, która zdaniem twórców Mavena jest odpowiednia dla każdego projektu. Jest taki nieelastyczny. A to, co dla wielu ludzi jest „Pro”, zarządzanie zależnościami, jest największym „wadą” IMHO. Absolutnie nie czuję się komfortowo, gdy maven pobiera słoiki z sieci i tracę sen z powodu niezgodności (tak, tryb offline istnieje, ale w takim razie po co miałbym mieć te wszystkie setki plików xml i sum kontrolnych). Decyduję, z których bibliotek korzystam, a wiele projektów ma poważne obawy dotyczące kompilacji zależnych od połączenia sieciowego.

Co gorsza, kiedy coś nie działa, jesteś całkowicie zagubiony. Dokumentacja jest do niczego, społeczność nie ma pojęcia.

Rok później chciałem to zaktualizować: nie mam już takiej opinii o społeczności Maven. Nie napisałbym tej odpowiedzi, gdyby pytanie padło dzisiaj. Obecną opinię dodam jako osobną odpowiedź.

To bardzo subiektywna odpowiedź, ale pytanie dotyczy opinii, więc ...

Lubię Mavena i tym bardziej mi się podoba, im lepiej go poznaję. Jedna rzecz wpływa jednak na moje odczucia co do tego: społeczność maven jest w dużej mierze skupiona wokół Sonatype („firma maven”, to tam pracuje wielu z Maven honchos), a Sonatype dość agresywnie naciska na swoje produkty korporacyjne na społeczność.

Przykład: Twitter „Maven Book” zawiera odsyłacze do rzekomego wprowadzenia do zarządzania repozytorium .

Przepraszamy, ale to „wprowadzenie” to w połowie informacja, w połowie prezentacja sprzedaży Nexusa. Quiz: czy są inni menedżerowie repozytoriów poza Nexusem i Nexusem Pro? Co to ma wspólnego z rzekomo otwartą książką Mavena? Och, tak, rozdział o zarządzaniu repozytorium został podzielony na osobną książkę ... o Nexusie. Huh. Jeśli wnoszę wkład do książki Maven, czy otrzymam opłatę za polecenie, jeśli spowoduję wzrost sprzedaży Nexusa?

Wyobraź sobie, że uczestniczysz w forum poświęconym programistom w języku Java i było jasne, że pracownicy Sun omawiający język Java zamierzali wykorzystać każdą możliwą okazję, aby porozmawiać o NetBeans i „NetBeans Pro”. Po pewnym czasie traci część poczucia wspólnoty. Nigdy nie miałem takiego doświadczenia z Antem.

Powiedziawszy to wszystko, uważam, że Maven jest bardzo interesującym i użytecznym systemem (nie nazywam go narzędziem, takim jak Ant, Maven jest szerszy) do konfiguracji tworzenia oprogramowania i zarządzania kompilacją. Zarządzanie zależnością jest czasami błogosławieństwem i przekleństwem, ale odświeża - iz pewnością nie jest jedyną zaletą, jaką oferuje Maven. Prawdopodobnie trochę za mocno reaguję na szyling Sonatype, ale moim zdaniem boli Mavena przez skojarzenie. Nie wiem, czy ktokolwiek podziela tę opinię.

Myślę, że Maven dostaje złą reputację, ponieważ narzuca strukturę twojemu projektowi, podczas gdy inne narzędzia, takie jak Ant, pozwalają całkowicie zdefiniować strukturę w dowolny sposób. Zgodziłem się również, że dokumentacja jest zła, ale myślę, że przede wszystkim zły rap, jaki dostaje Maven, wynika z tego, że ludzie są tak przyzwyczajeni do Ant.

Za dużo magii.

Ponieważ niezadowoleni ludzie narzekają, a zadowoleni nie mówią, że są zadowoleni. Chodzi mi o to, że jest o wiele więcej zadowolonych użytkowników maven niż niezadowolonych, ale później robią więcej hałasu. Jest to również powszechny wzorzec z prawdziwego życia (ISP, operator telefoniczny, transport itp.).

Najważniejszą dla mnie kwestią jest to, że Maven, gdy nie jest poprawnie skonfigurowany, może nie tworzyć powtarzalnych kompilacji z powodu:

• zawodne repozytoria zdalne;
• zależności od wtyczek i bibliotek z wersjami SNAPSHOT lub bez wersji.

Porównaj to z budową mrówek, która - choć gadatliwa i męcząca IMO - działa, ponieważ wszystkie słoiki są sprawdzane lokalnie.

Dobre jest to, że problemy można rozwiązać:

• użyj własnego repozytorium Maven , które stało się bardzo proste, używam Archivy z dobrymi wynikami;
• zawsze poprawnie wersjonuj swoje zależności. Maven zaczął blokować wersje wtyczek w super-POM zaczynające się od 2.0.8 lub 2.0.9 i wszystkie twoje zależności powinny znajdować się w wydanych wersjach.

świetny pomysł - słaba realizacja.

Niedawno przeniosłem projekt z Ant do Maven. Pod koniec działało dobrze, ale musiałem użyć dwóch różnych wersji wtyczki maven-assembly-plugin i maven-jar-plugin w tym samym pom (dostałem dwa profile), ponieważ to, co działało w jednej wersji, było zepsute w innej.

Więc to był niezły ból głowy. Dokumentacja nie zawsze jest świetna, ale muszę przyznać, że wyszukiwanie w Google odpowiedzi było stosunkowo łatwe.

upewnij się, że zawsze określasz wersje wtyczek, których używasz. Nie oczekuj, że nowa wersja będzie wstecznie kompatybilna.

Myślę, że kontrowersje wynikają z faktu, że maven wciąż ewoluuje, a proces ten jest czasami bolesny.

pozdrowienia

v.

Lubię maven. Używam go od wersji wcześniejszej niż 1.0. To potężne narzędzie, które w sumie zaoszczędziło mi sporo czasu i poprawiło moją infrastrukturę programistyczną. Ale rozumiem frustrację niektórych ludzi. Widzę 3 rodzaje frustracji:

1. gdzie przyczyny są rzeczywistymi problemami (np. gadatliwe POM, brak dokumentacji),
2. niektóre to dezinformacja (np. „musisz mieć połączenie z Internetem, aby zbudować” - nieprawda - nie rób tego, można tego uniknąć),
3. część z tego jest upuszczana w maven, ale tak naprawdę ktoś inny jest winny („nie strzelaj do posłańca”).

W pierwszym przypadku prawdziwe problemy - cóż, oczywiście, są problemy, POM są gadatliwe, dokumentacja mogłaby być lepsza. Mimo to możliwe jest uzyskanie dobrych wyników z maven w krótkim czasie. Wzdrygam się za każdym razem, gdy dostaję projekt zbudowany z ant i próbuję zaimportować to do mojego IDE. Konfiguracja struktury katalogów może zająć dużo czasu. w przypadku maven to tylko przypadek otwarcia pliku POM w IDE.

W drugim przypadku Maven jest złożony, a nieporozumienia są powszechne. Jeśli maven 3 może znaleźć sposób na rozwiązanie tej złożoności (lub nawet postrzeganej złożoności), byłoby dobrze. Maven wymaga znacznych inwestycji, ale z mojego doświadczenia wynika, że ​​inwestycja szybko się zwraca.

Jeśli chodzi o ostatni punkt, myślę, że zastrzeżenie dotyczące przechodnich zależności Mavena jest prawdopodobnie najbardziej znanym przykładem.

Zależności przechodnie są naturą prawdziwego oprogramowania wykorzystującego ponowne użycie. Biblioteki DLL systemu Windows, pakiety Debiana, pakiety java, pakiety OSGi, a nawet plik nagłówkowy C ++ zawierają wszystkie zależności i cierpią na problem z zależnościami. Jeśli masz dwie zależności i każda używa innej wersji tej samej rzeczy, musisz spróbować jakoś to rozwiązać. Maven nie próbuje rozwiązać problemu zależności, ale raczej wysuwa go na pierwszy plan i zapewnia narzędzia pomagające w zarządzaniu problemem, takie jak zgłaszanie konfliktów i zapewnianie spójnych zależności dla hierarchii projektów, a w rzeczywistości zapewnia absolutną kontrolę nad zależności projektu.

Podejście polegające na ręcznym dołączaniu zależności do każdego projektu (jeden z plakatów mówi, że sprawdza wszystkie zależności w kontroli źródła) wiąże się z ryzykiem użycia niewłaściwej zależności, takiej jak przeoczone aktualizacje, gdy biblioteka jest aktualizowana bez sprawdzania aktualizacji pod kątem jej zależności. W przypadku projektu dowolnej wielkości ręczne zarządzanie zależnościami z pewnością doprowadzi do błędów. Dzięki maven możesz zaktualizować używaną wersję biblioteki i uwzględniać poprawne zależności. W celu zarządzania zmianą możesz porównać stary zestaw zależności (dla twojego projektu jako całości) z nowym zestawem, a wszelkie zmiany można dokładnie przeanalizować, przetestować itp.

Maven nie jest przyczyną problemu zależności, ale czyni go bardziej widocznym. W rozwiązywaniu problemów z zależnościami maven czyni dowolną zależność „poprawioną” jawnie (zmiana w POM, nadpisująca zależność), a nie niejawną, jak ma to miejsce w przypadku ręcznie zarządzanych plików JAR w kontroli wersji, gdzie pliki słoików są po prostu obecne, bez niczego obsługują pogodę, czy są właściwą zależnością, czy nie.

Uważam, że Maven ma złą reputację, ponieważ większość krytyków nie zauważyła kombinacji Maven + Hudson + Sonar . Gdyby tak było, pytaliby „jak mam zacząć”?

Niektóre z moich zwierzaków irytuje Maven:

• Definicja XML jest bardzo niezgrabna i rozwlekła. Czy nigdy nie słyszeli o atrybutach?

• W swojej domyślnej konfiguracji zawsze przeszukuje sieć przy każdej operacji. Niezależnie od tego, czy jest to do czegoś przydatne, potrzeba dostępu do Internetu w celu „wyczyszczenia” wygląda wyjątkowo głupio.

• Domyślnie, jeśli nie będę ostrożnie określał dokładnych numerów wersji, najnowsze aktualizacje zostaną usunięte z sieci, niezależnie od tego, czy te najnowsze wersje wprowadzają błędy zależności. Innymi słowy, jesteś na łasce zarządzania zależnością innych ludzi.

• Rozwiązaniem całego tego dostępu do sieci jest wyłączenie go poprzez dodanie -oopcji. Ale musisz pamiętać, aby go wyłączyć, jeśli naprawdę chcesz zaktualizować zależności!

• Innym rozwiązaniem jest zainstalowanie własnego serwera „kontroli źródła” dla zależności. Niespodzianka: większość projektów ma już kontrolę źródła, ale działa ona bez dodatkowej konfiguracji!

• Kompilacje Mavena są niezwykle powolne. Majstrowanie przy aktualizacjach sieciowych łagodzi ten problem, ale kompilacje Mavena są nadal wolne. I okropnie gadatliwie.

• Wtyczka Maven (M2Eclipse) integruje się najsłabiej z Eclipse. Eclipse integruje się w miarę płynnie z oprogramowaniem do kontroli wersji i Ant. W porównaniu z nim integracja Mavena jest bardzo niezgrabna i brzydka. Czy wspomniałem wolno?

• Maven nadal jest buggy. Komunikaty o błędach są nieprzydatne. Zbyt wielu programistów cierpi z tego powodu.

Dobre pytanie. Właśnie zacząłem duży projekt w pracy, a częścią poprzednich projektów było wprowadzenie modułowości do naszego kodu.

Słyszałem złe rzeczy o maven. Właściwie to wszystko, co kiedykolwiek o tym słyszałem. Patrzyłem na wprowadzenie go, aby rozwiązać koszmar uzależnienia, którego obecnie doświadczamy. Problem, który widziałem w przypadku Mavena, polega na tym, że jest dość sztywny w swojej strukturze, tj. Musisz dostosować się do jego układu projektu, aby działał dla Ciebie.

Wiem, co powie większość ludzi - nie musisz dostosowywać się do struktury. Rzeczywiście, to prawda, ale nie będziesz o tym wiedział, dopóki nie przekroczysz początkowej krzywej uczenia się, w którym zainwestowałeś zbyt dużo czasu, aby to wszystko wyrzucić.

Mrówka jest obecnie często używana i uwielbiam ją. Biorąc to pod uwagę, natknąłem się na mało znanego menedżera zależności o nazwie Apache Ivy . Ivy bardzo dobrze integruje się z programem Ant i można szybko i łatwo uzyskać podstawową konfigurację pobierania i działanie JAR. Kolejną zaletą Ivy jest to, że jest bardzo potężny, ale dość przejrzysty; możesz łatwo przenosić kompilacje za pomocą mechanizmów takich jak scp lub ssh; pobieranie zależności „łańcuchowych” przez systemy plików lub zdalne repozytoria (kompatybilność repozytorium Maven jest jedną z jego popularnych funkcji).

To wszystko powiedziawszy, uznałem to za bardzo frustrujące w końcu - dokumentacji jest mnóstwo, ale jest napisana złym angielskim, co może zwiększyć frustrację podczas debugowania lub próby ustalenia, co poszło nie tak.

Mam zamiar ponownie odwiedzić Apache Ivy w pewnym momencie podczas tego projektu i mam nadzieję, że będę działał poprawnie. Jedną z rzeczy było to, że pozwolił nam jako zespołowi ustalić, od jakich bibliotek jesteśmy zależni i uzyskać udokumentowaną listę.

Ostatecznie myślę, że wszystko sprowadza się do tego, jak pan pracować jako pojedynczy / zespół i co Ci potrzebne, aby rozwiązać swoje problemy z zależnościami.

Przydatne mogą być następujące zasoby dotyczące Ivy:

• Porównanie Apache Ivy i Maven 2
• Często zadawane pytania dotyczące Apache Ivy
• Lista funkcji Apache Ivy

Uwielbiam Mavena - zwiększa produktywność i bardzo się cieszę, że nie używam już Anta (uff!)

Ale gdybym mógł coś zmienić, byłoby to:

1. Spraw, aby pom.xmlplik był mniej szczegółowy
2. Ułatw dołączanie plików .jars nie z repozytorium.

Jest wiele powodów, dla których ludzie nie lubią Mavena, ale spójrzmy prawdzie w oczy, są one bardzo subiektywne . Maven dzisiaj z kilkoma dobrymi (i darmowymi) książkami, lepszą dokumentacją, większym zestawem wtyczek i wieloma referencyjnymi pomyślnymi kompilacjami projektów to nie to samo Maven, co rok lub dwa lata temu.

Używanie Mavena w prostych projektach jest bardzo łatwe, przy większych / skomplikowanych projektach potrzebna jest większa wiedza i głębsze zrozumienie filozofii Mavena - może na poziomie firmy jest to stanowisko dla guru Mavena, takiego jak administrator sieci. Głównym źródłem stwierdzeń o nienawiści Mavena jest często ignorancja .

Kolejnym problemem dla Mavena jest brak elastyczności, jak np. W Ant. Ale pamiętaj, że Maven ma zestaw konwencji - trzymanie się ich wydaje się być trudne na początku, ale na końcu często oszczędza się przed problemami.

Obecny sukces Mavena potwierdza jego wartość. Oczywiście nikt nie jest doskonały, a Maven ma pewne wady i dziwactwa, ale moim zdaniem Maven powoli kołysze swoimi przeciwnikami.

Nie powiedziałbym, że ma tak złą reputację, ile ma mieszaną reputację. Jeśli Twój projekt jest zgodny z paradygmatem „konwencji zamiast konfiguracji” zalecanym przez Mavena, możesz uzyskać z niego wiele korzyści. Jeśli twój projekt nie pasuje dobrze do światopoglądu Mavena, może stać się ciężarem.

W tym celu, jeśli masz kontrolę nad projektem, Maven może być najlepszym rozwiązaniem. Ale jeśli tego nie zrobisz, a układ jest określany przez kogoś, kto nie jest fanem Mavena, może to być więcej kłopotów niż warto. Najszczęśliwsze projekty Mavena to prawdopodobnie te, które zaczęły się jako projekty Mavena.

Według mnie jest tyle zalet, ile minusów, jeśli chodzi o używanie maven vs ant do projektów wewnętrznych. Jednak w przypadku projektów typu open source myślę, że Maven wywarł ogromny wpływ na ułatwienie tworzenia wielu projektów. Nie tak dawno temu trwało kilka godzin, aby skompilować przeciętny projekt OSS Java (oparty na mrówkach), musiał ustawić mnóstwo zmiennych, pobrać zależne projekty itp.

Z Mavenem możesz zrobić wszystko, co możesz zrobić z Antem, ale tam, gdzie Ant nie zachęca do żadnych standardów, Maven zdecydowanie sugeruje przestrzeganie jego struktury, inaczej będzie to wymagało więcej pracy. To prawda, że ​​niektóre rzeczy są trudne do skonfigurowania z Mavenem, co byłoby łatwe do zrobienia z Ant, ale efekt końcowy jest prawie zawsze czymś, co jest łatwiejsze do zbudowania z perspektywy ludzi, którzy chcą po prostu sprawdzić projekt i zacząć.

Jeśli zamierzasz postawić swoją firmę lub pracę na projekt deweloperski, chcesz mieć kontrolę nad fundamentami - czyli systemem budowania. Z Maven nie masz kontroli. Jest deklaratywny i nieprzejrzysty. Programiści maven-frameworka nie mają pojęcia, jak zbudować przejrzysty lub intuicyjny system i wynika to jasno z danych wyjściowych dziennika i dokumentacji.

Zarządzanie zależnościami jest bardzo kuszące, ponieważ może to samo z tobą przez jakiś czas na początku projektu, ale ostrzegam, jest zasadniczo zepsute i ostatecznie spowoduje wiele bólów głowy. Kiedy dwie zależności mają niekompatybilne przejściowe zależności, zostaniesz zablokowany przez gniazdo szczura złożoności, które zepsuje kompilację dla całego zespołu i zablokuje rozwój na kilka dni. Proces budowania z Maven jest również notorycznie niespójny dla różnych programistów w twoim zespole z powodu niespójnych stanów ich lokalnych repozytoriów. W zależności od tego, kiedy programista utworzył swoje środowisko lub nad innymi projektami, nad którymi pracuje, będą miały różne wyniki. Przekonasz się, że usuwasz całe lokalne repozytorium i Maven ponownie pobiera pliki JAR znacznie częściej niż przy pierwszej konfiguracji dla gałęzi deweloperów. Uważam, że OSGI to inicjatywa, która próbuje rozwiązać ten podstawowy problem. Powiedziałbym, że być może skoro coś musi być tak złożone, to podstawowa przesłanka jest błędna.

Jestem użytkownikiem / ofiarą mavena od ponad 5 lat i muszę powiedzieć, że zaoszczędzi ci to znacznie więcej czasu, aby po prostu sprawdzić swoje zależności w repozytorium źródłowym i napisać ładne i proste zadania mrówek. Z ant, wiesz DOKŁADNIE, co robi twój system kompilacji.

Doświadczyłem wielu, wielu tygodni straconych ludzi w kilku różnych firmach z powodu problemów z Maven.

Niedawno próbowałem przywrócić do życia stary projekt GWT / Maven / Eclipse i 2 tygodnie później, nadal nie mogę go konsekwentnie budować. Nadszedł czas, aby zmniejszyć swoje straty i rozwinąć się za pomocą mrówek / zaćmień, o których myślę ...

Krótka odpowiedź: bardzo trudno mi było utrzymywać system kompilacji Mavena i chciałbym jak najszybciej przejść na Gradle.

Pracuję z Mavenem od ponad czterech lat. Nazwałbym siebie ekspertem w budowaniu systemów, ponieważ w ostatnich (co najmniej) pięciu firmach, w których byłem, przeprowadzałem generalne remonty infrastruktury budowania / wdrażania.

Niektóre z lekcji, których się nauczyłem:

• Większość programistów nie spędza dużo czasu na myśleniu o budowaniu systemów; w rezultacie kompilacja zamienia się w bałagan spaghetti z hackami, ale doceniają to, gdy ten bałagan zostanie wyczyszczony i zracjonalizowany.
• Jeśli chodzi o złożoność, wolałbym mieć przejrzysty system, który ujawnia złożoność (jak Ant), niż taki, który próbuje uprościć złożone rzeczy, narzucając sztywne ograniczenia, jak Maven. Pomyśl o Linuksie i Windowsie.
• Maven ma wiele luk w funkcjonalności, które wymagają bizantyjskich obejść. Prowadzi to do niezrozumiałych i niemożliwych do utrzymania plików POM.
• Ant jest bardzo elastyczny i zrozumiały, ale pliki Ant mogą też stać się całkiem duże, ponieważ mają tak niski poziom.
• W przypadku każdego znaczącego projektu programiści muszą stworzyć własną strukturę kompilacji / wdrażania wykraczającą poza to, co zapewnia narzędzie; przydatność konstrukcji do projektu ma duży wpływ na łatwość jej utrzymania. Najlepsze narzędzia będą wspierać Cię w tworzeniu struktury, a nie walczyć z Tobą.

Zajrzałem trochę do Gradle i wygląda na to, że ma potencjał, aby być najlepszym z obu światów, umożliwiając mieszankę deklaratywnego i proceduralnego opisu kompilacji.

Jest to bardziej skomplikowane niż język, którego użyłeś do napisania swojego projektu. Właściwa konfiguracja jest trudniejsza niż rzeczywiste programowanie.

Przedzierałem się przez większość / wszystkie wspomniane tutaj negatywy i podobne zastrzeżenia kolegów z drużyny i zgadzam się z nimi wszystkimi. Ale wytknąłem to i nadal będę to robić, trzymając się mocno jednego celu, który naprawdę spełnia tylko maven (a może gradle).

Jeśli jesteś optymalizacji dla rówieśników (open source programistów ), mrówka / make / cokolwiek zrobi. Jeśli dostarczasz funkcjonalność innym użytkownikom ( użytkownikom ), wystarczy maven / gradle / etc.

Tylko maven pozwala wydać mały pakiet kodu źródłowego + poms (bez osadzonych plików jarów zależności lib / binarnych z tajemniczymi nazwami i bez informacji o zależnościach) z dobrze udokumentowanym standardowym układem projektu, który może być załadowany przez dowolne IDE przez kogoś, kto nie wchłonął specyficzne konwencje układu deweloperów. Istnieje procedura instalacji za pomocą jednego przycisku (instalacja mvn), która buduje wszystko, uzyskując wszelkie brakujące zależności.

W rezultacie użytkownicy mogą łatwo wejść na rampę, aby znaleźć drogę do kodu, gdzie poms mogą wskazać im odpowiednią dokumentację.

Poza tym (nieodzownym) wymogiem, nie lubię mavena tak samo jak wszyscy.