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!

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.

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.

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.

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

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.

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.

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.

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.