Hur bra är Maven egentligen?
- tor 31 jan, 2008 kl 21:57
- 11 kommentarer
- Ant, Verktyg
Håller på mycket med byggskript på sistone och har funderat mycket om vad jag skall välja. Jag har tidigare jobbat med Ant och lite med Maven. Sist gång jag jobbade med maven så slutade det med att jag la ner det på grund av buggar men så funderar jag på det igen men det råder delade meningar i olika bloggar om hur bra det egentligen är?
Det som känns jobbigt med maven är att man måste läsa på mycket för att kunna använda det ordentligt. Det finns mycket att ta in och mycket att konfigurera och frågan är om det är så mycket snabbara en att bara skriva ner det snabbt i Ant. Det man måste tänka på är ju också att även efterföljande utvecklare måste lära sig allt igen. Självklart måste man lära sig ant också men det är mycket lättare att ta till sig. Maven skall ju egentligen vara på högre nivå än Ant på samma sätt som relationen mellan Java och C samt C och assembler men på nått sätt så känns det mycket enklare att bara hoppa på Ant än Maven. Jag baserar inte detta på erfarenhet av Maven2 så det är mer en känsla. I en drömvärld så hade jag kunnat använda Gant men det visade sig snabbt att det var både ostabilt och saknade bra IDE stöd så ja la ner det spåret.
I den här(samma som ovan) bloggen så tas olika för och nackdelar upp. Vad tycker ni som läser detta inlägg? Är maven guds/allahs/buddahs/odens gåva till mänskligheten eller är det ”EJB2’s motsvarighet i byggsystem” som nån skrev som kommentar i länken ovan? Vad är det som talar för och emot Maven? Är kanske Ant+Ivy den gyllene medelevägen?
Enligt min erfarenhet är det bra mycket lättare att sätta sig in i maven än att gång på gång sätta sig in i ant-amatörernas eviga hackande. Behöver man egentligen bygga sina javaprojekt på så många olika sätt??
Och när jag säger maven menar jag naturligtvis Maven2. ”Maven 1″ var ett misslyckat experiment.
Vi har diskuterat detta innan. Se här.
Om man skall försöka tolka diskussionerna så verkar det som om det finns många som har problem med maven och saker som verkar ”svåra” och odkumenterade. Jag kan ha fel på detta men maven är väl designat för att förenkla byggandet men om det är så, så kan man ju fundera över varför så många klagar på att det är så onödigt komplext.
Att det är så skillda åsikter om maven kanske just beror på att det finns många olika sätt att bygga java och många olika scenarion och special krav. Det kanske är dom som har special krav som just får problem med maven.
Efter att ha testat Maven(2) i mitt nuvarande uppdrag och även i andra mindre projekt så har jag insett några av de stora bristerna
Till att börja med så är dokumentationen näst intill obefintlig. Detta lilla som står kan hjälpa dig för att skapa motsvarigheten till ”Hello world”.
Många Maven repositories följer inte de senaste versionerna av de releaser som gjorts för olika komponenter. JBoss är ett exempel som fortfarande inte fått ordning på Maven för JBoss Seam (vilket är anledningen till att vi inte kan använda det i aktuellt projekt). Resultatet blir att du inte kan få in din buggfix utan att själv sätta upp ett repository som du underhåller.
Konfigurationen görs i XML men det finns inget XML-schema definerat för Maven. Detta gör att det blir väldigt lätt att göra fel i konfigurationen. Detta liknar en av de mest kritiserade bristerna i Spring, där XML-schemat inte ansågs vara komplett p.g.a. avsaknaden av typer o.s.v.
Det är för många nya och helt okända koncept som det inte finns någon motsvarighet till för en van Java-utvecklare. Dependency-hanteringen (ful-svengelska) är jättebra och lättförståelig, men jag har fortfarande problem med att förstå vad archetypes ska vara bra till, än mindre profiles. Det känns som man gjort samma typ av misstag som Eclipse gjort med sina vyer och perspective.
Offline-mode borde vara standard. Att gå ut och kolla alla repostories borde vara en explicit åtgärd. Maven-stödet i IntelliJ har lagt till detta som default, men det borde vara något Maven gör från början.
Asch, nu råkade jag peta in min stora kommentar i fel tråd (den Peter länkade till), men jag missade också att fylla på med följande:
Offline: ja. När man fixade cvs och skrev subversion kom man ihåg detta. Synd att maven 2 inte ordnade det. (Don Brown jobbar som sagt på detta, samt att köra mot /WEB-INF/lib eller motsv för de som _vill_ dra ner libbar själva).
Svårigheterna kring archetypes och profiles bör vara en svårighet för få – inte behöver väl hela teamet ha koll på detta?
Ja, det är inte ovanligt att de stora repositoriesarna ligger efter. Som tur är krävs inte mycket för att sätta upp ett eget repo (vilket borde vara naturligt att göra) och att lägga till en jar som man hämtat hem själv är verkligen en no-brainer.
”Hur bra är maven egentligen?”
Åsikt: Om man klarar att hålla sig inom mavens struktur/modell så sparar det tid för projektet och avlastar utvecklingsteamet genom att ta bort nästan allt arbete kring byggprocessen. I min mening är detta högt önskvärt och tillför mer positivt till projektet än det negativa som verktygets brister emellanåt kan medföra.
Fredrik: Om det är svårigheter kring archetypes och profiles så spelar det väl ingen roll om det bara är en person eller om hela teamet behöver ha koll på det? Det tar väl ändå lika lång tid att hantera och problemet är som sagt kvar.
Jag tror mer på de ”lättare” verktygen, såsom Ivy från Ant-projektet (http://ant.apache.org/ivy/). Dokumentationen är riktigt bra, den har stöd för Maven-respositories så du kan börja använda det redan idag och konfigurationsfilen har ett XML Schema för validering.
Maven är ett bra koncept med dålig implementation. Det är ju trots allt rätt många som klagar på det.
Det man är rädd för är ju att man skall lägga veckor på att implementera ett nytt byggsystem och sen hamna i en återvänds gränd och bli tvungen att gå tillbaka till Ant. Detta hände sist gång jag provade maven (dock version 1). Men med tanke på att det är så många som fortfarande klagar på maven så är det ju trotts allt en risk.
Så jag kan inte utala mig och säga att manven2 är dåligt eller inte utan kan bara konstatera att det är en risk inblandad att gå den vägen. Det är ju alltid risk att använda sig av ett 3:dje parts system men i det här fallet så är det ju en betydlig skara nej sägare :-).
Erik:
http://www.sonatype.com/book/
http://maven.apache.org/maven-v4_0_0.xsd
Jag skrev om Maven här på bloggen för en tid sedan. Jag tycker Mavens beroendehantering är ett steg i rätt riktining, även om den inte på långa väger uppfyller alla krav.
Problemet med Maven är precis som Erik nämde att det är ruggigt odokumenterat. Och det är rätt buggigt, åtminstone är alla miljoner plugginner det.
Maven kommer att behöva gå igenom både 3.0 och 4.0 innan vi har nåt riktigt användbart. Kanske har dessutom folket lärt sig förstå hur man ska använda ett sånt här byggverktyg.
Det här är kanske lite sent inlägg. Men jag måste ändå säga att efter gått igenom ett 20 tal open source .NET projekt så är maven att föredra. Det fanns inte ett open source projekt som lagt källkod, beroenden, resurser på samma sätt. Varje projekt hade sin struktur, och egna ”goals” i nant, msbuild, osv.
Med maven så är allt det här redan uppstyrt i de olika src katalogerna. Jag skulle säga att mavens fördel är standardiseringen är dess största fördel. För om man kommer till ett nytt projekt med maven, så kan mkt lätt bygga projektet, hitta filerna och veta exakt vilka goals man behöver för att tex köra testerna. Maven har sin byggcykel som är ganska lätt och förstå. Skulle jag skapa ett open source projekt så skulle jag välja maven för att det mesta jobbet är redan gjort av någon annan.
Här kommer ännu ett riktigt sent inlägg i tråden. Fredrik Wendt skriver tidigare ”att lägga till en jar som man hämtat hem själv är verkligen en no-brainer.”
Jag skulle vilja påstå att det är precis tvärtom. Att lägga till en ny jar kräver mycket tankeverksamhet.
Oavsett vilket beroendehanteringssystem som används (Maven, Ivy eller annat) så springer jag gång på gång på feldeklarerade beroenden.
En anledning till detta är att många libbar helt saknar versionsinformation om sina beroenden, andra kan tillhanda hålla information som visar sig opålitlig eftersom en md5sum visar olika resultat.
Jag har ännu inte fått förmånen att testa Ivy, men jag ska skulle definitivt inte tveka att använda det systemet i kombo med ett internt repository där man har full kontroll. Ivy verkar ha bra stöd för att slimma ner beroende trädet till ett absolut minimum.
Oj, jag har helt missat alla svar här. (Var är [ ] send me e-mail updates on this thread?)
Generellt sett så håller jag fortfarande fast vid den åsikt jag skrev tidigare – håller man sig inom mavens ramar så har man mängder att vinna, och lite att förlora pga dess negativa sidor.
@Jon: Vi använder kanske olika källor – de repos jag använder har sällan felaktigt uppsatta/deklarerade beroenden. Det problem jag faktiskt stött på är det klassiska med att flera libbar försöker använda olika versioner av samma logging-lib, t ex slf4j, commons-logging, och även xml-libbar. Problemet uppstår i runtime och problemet är inte unikt för maven – effekten blir den samma om man använder ivy istället för att dra hem jar-filerna i fråga.
Jag kan inte motivera att man skall lägga pengar i varje projekt på att få till och underhålla ant-script som gör samma saker, om och om igen. Jag säger inte att maven är underhållsfritt, men det är iaf ett steg åt standardiserat bygge och man får massor (av dokumentation, testning och rapporter) gratis som man kan sätta upp en gång och sedan ärva. (Kan man ha motsvarande ”parent” i ant, remote, eller är det copy-paste som gäller?)
Precis som redsolo vittnar om så betyder inte ”fritt val” att det blir lättare för andra att ta sig till projekt (eller ärva/få i knät).
Ett fall där ant är att föredra är när många oortodoxa steg skall utföras för att bygga/skeppa iväg ett projekt. Att vända ut och in på maven genom obskyr konfiguration av plugins kan vara riktigt svårt att läsa och se vad/när de kickar in. Av alla X antal mavenprojekt som jag sett så är det till dags dato dock bara en gång jag önskat att detta istället sköttes med ant.
@Erik: Du skrev att Seam inte hade packeterat sina saker i något maven-repo och det var en show-stopper. I alla de maven-repo/mirror/proxys jag sett (Nexus, archiva och den där lilla) är det inte svårt att ta en jar och tanka upp den och ev beroenden. Det är lite mer jobb än att lägga i en WEB-INF/lib-katalog, men förhoppningsvis så har man gjort någon annan avdelning på företaget eller kommande projekt en tjänst. Det är inte svårt att sätta upp en lokal proxy (och det sparar ju på bandbreddsbehovet).
@Erik: Jag låter hellre en person sätta upp en profil, posta den på en wiki och sedan säga ”kör maven” än att tvinga varje team lära sig varje projekts utformning, byggen, beroenden. Detta eftersom jag tror att det blir mycket mindre jobb totalt sett.
@Per: Om du skulle köra huvudet i väggen igen med maven får du se till att höra av dig!