Upravo sam počeo da ga koristim, tj. morao sam, da bih startovao GeoTools primere. Zapravo sam samo instalirao (raspakovao) otkucao onako kao piše u nekom uputstvu i to je to. Moram priznati da ne kapiram u čemu je fora. Ono malo što sam skapirao je da, kao, maven sam može da provali u kom je jar-u potrebna klasa za kompajliranje. Koliko sam još shvatio, donekle se prepliće sa Ant-om, ali i može da sarađuje. A možda je zamišljen da zameni ant ?

Posetio sam par puta jakarta stranicu koja se tiče mavena, ali nisam imao vremena da se udubljujem.

Hm, nisam bas siguran...

Ja ga koristim zadnje vreme. Mišljenje? Pa prilično je izmešano, objasniću i zašto. Pre toga, moram reći da sam pre toga uvek koristio Ant, i bio zadovoljan njime jer sam mogao sa njim da radim sve što sam hteo i nisam imao želju da prelazim na Maven. Znači na Maven sam krenuo posle višegodišnjeg iskustva u radu sa Ant-om pa možda neke stvari teže prihvatam jer sam navikao kako to ide u Ant-u. Btw, Maven nije SAMO zamena za Ant, ali može u potpunosti da ga zameni. Znači ima mnogo širi opseg i dosta stvari u Antu ne postoji pa je teško praviti poređenje.

Elem, kada sam počeo da ga koristim bio sam oduševljen:

- Svidelo mi se to što je sve predefinisano, pa uz par instrukcija možeš krenuti brzo da radiš. Naravno, ako koristiš njihove preporuke za strukturu foldera. Znaš gde treba da staviš klase, gde resource fajlove gde klase/resource za testiranje i to sve fino radi. Potrebno je vrlo malo stvari definisati u POM za projekat.
- Dobra je stvar to što ima podršku za alate. Konkretno, ja koristim Eclipse i uvek me nerviralo što moram ručno dodavati sve jar fajlove i u Ant i u Eclipse. Kod Mavena, postoji goal koji generiše konfiguracione fajlove za Eclipse na osnovu njegovog pom-a. Štaviše, postoji i podrška za Eclipse WTP što je super ako ga koristite. Sa Antom, bi sve morali ručno da definišete, što dugo traje. Pogotovo kada treba novom developeru podesiti okruženje.
- Sam Maven vas tera da koristite best-practices tako da je teže napraviti lošu organizaciju projekta nego kada koristite Ant. Kod Anta krećete od praznog build.xml-a dok Mavena ima predefinisane goal-ove.
- Za Maven postoji brdo pluginova pri čemu se jarovi za njih ne moraju ručno instalirati već se to tokom builda automatski skida sa Interneta.

Posle određenog vremena oduševljenje je preraslo u razočaranje. Evo nekih razloga:
- Maven ima koncept repozitorijuma, tj. ideja je da se jar fajlovi ne ubacuju na CVS/SVN, već se tokom samog builda sa interneta skidaju potrebne biblioteke. E sad koliko je ovo dobro je kranje diskutabilno. Prvi build kada se instalira Maven i skine projekat na kojem radite sa CVS/SVN traje užasno dugo, jer Maven prvo skida sve što je potrebno njemu samom (ovo se događa i kasnije kada koristite neke nove goal-ove) kao i za sam projekat. Nevolja je kada imate lošu konekciju ili kada je neki od sajtova nedostupan jer će onda build pući.
- Zbog takvog načina rada, Maven mi je uvek sporiji od Anta jer i za jednostavne buildove on mora da isproverava sve na Internetu što dosta usporava.
- Lično sam skeptičan prema ideji da se skidaju najnovije verzije biblioteka, jer nikada ne znate da li će to biti 100% kompatibilno sa vašim projektom.
- Nekako mi sam output Mavena deluje nepregledno. Za razliku od Anta koji ispisuje samo nepohodne informacije i ono što sami definišete u build.xml, ovde dobijate mnogo više informacija koje vam u principu i ne znače puno.

Javljali su mi se i mnogi drugi problemi koji su u početku bili frustrirajući. Međutim, posle nekog vremena i vršljanja po dokumentaciji, čovek nađe rešenje za svaki od problema. Tako da Mavenu možete reći da hoćete tačno određenu verziju biblioteke, a ne uvek najnoviju. Takođe, postoji opcija -o za "offline" rad, gde Maven ne proverava da li postoje novije verzije biblioteka na Internetu, već koristi one iz svog repozitorijuma.

Na kraju, mislim da je Maven generalno dobar alat. Omogućava da uz malo pročitane dokumentacije i par linija koda kreirate kompleksne buildove sa sve tesitranjem, deploymentom i sl. za šta bi u Antu trebalo više vremena/kodiranja. Međutim, kada se stvari malo zakomplikuju onda mi se čini da sa Antom brže nađete rešenje jer je sam alat jednostavniji. Kod Mavena je sve super dok poštujete njihove preporuke jer onda stvarno nemate mnogo posla, dok je kod Anta totalno svejedno kakvu strukturu projekat ima jer ne postoji nikakav default. Zato mi se čini da je Ant lakše ugurati u postojeći projekat, nego Maven, ali je zato sa Mavenom mnogo lakše krenuti sa novim projektom. Takođe, ako prihvatite njihovu filozofiju i ideju kako treba organizovati kod, onda development postaje mnogo lakši jer ljudima treba mnogo manje da se snađu u novom projektu.

Dejane, hvala na opsirnom odgovoru, mislim da sam uhvatio poentu

Svakako zvuci interesantno, potrudicu se da mu dam sansu!

V

Nisam neki znalac Mavena, znam osnovne koncepte, ali cini mi se da on to radi samo prvi put.
Naime Maven ce napraviti na tvojoj masini lokalni repozitorijum sa svim potrebnim jar-ovima tako da prvo
proverava njega a zatim ako tamo ne nadje onda ide na net.
Za svaki sledeci projekat uzece jar-ove sa tvoje masine.
Recimo za LAN moze da se napravi centralni repozitorijum tako da imas jos jedan sloj pre interneta:
proverava prvo tvoj racunar, zatim taj centralni repozitorijum, zatim Maven repozitorijum na netu.

Pozdrav!

Pažljivo sam pročitao sve postove, a posebno i iscrpan post Dejana. I nameće se pitanje/odgovor : dakle, maven je novi i malo drugačiji ant ?
Nikad nisam voleo krute programerske alate, sa gomilom predefinisanih osobenosti. Oni ti, naravno, nude da brzo i efikasno uradiš nešto što je zamišljeno da se radi, ali, poželiš li da kreneš "svojim putem", i da uradiš nešto drugo, nailaziš na barijere, zidove i kočnice.
No, dobro. Naučili smo Ant, pa ćemo i taj maven, nema nam druge.

Maven pravi lokalni repozitorijum na tvojoj mašini i odatle uzima jar fajlove, ali će takođe, po defaultu, proveriti da li postoji novija verzija biblioteke koju koristi. Ukoliko ne postoji, koristiće verziju iz repozitorijuma, a ako postoji onda će je skinuti i smestiti i nju u repozitorijum. Opet kažem moguće je specificirati tačno određenu verziju biblioteke i u tom slučaju Maven neće imati potrebe da je traži na netu ako je već ima u repozitorijumu. Takođe moguće je koristiti offline mod u kom slučaju se uvek koristi samo repozitorijum.

Dobra stvar sa repozotorijumom je što se smanjuje dupliranje biblioteka, jer sa Antom mi je uvek bilo najlakše da jarove smestim u neki lib folder projekta i smestim i to na CVS/SVN, što znači da se veliki broj biblioteka duplira za svaki projekat. S druge strane, kada su jarovi u samom projektu uvek znate na čemu ste.



Tačno. Moguće je specificirati i više repozitorijuma i na Internetu gde će se tražiti biblioteke. Po defaultu se koristi ibiblio.org





U principu mu je glavna funkcija ista kao i kod Anta (build projekta) mada u je opseg daleko širi. Maven ima neku svoju filozofiju koja je popularna u poslednje vreme (hint: Ruby on Rails) a to je da za sva podešavanja postoji neki logičan default što u većini slučajeva smanjuje broj linija koda. Takođe mnogo je "inteligentniji" od Anta pošto radi mnogo više stvari i "zna" mnogo više o projektu, što će se nekom svideti a nekome i ne. Maven sa default podešavanjima može da izgeneriše sve i svašta o tvom projektu (sajt, razne izveštaje, javadoc itd).

Inače, ako vam treba još informacija o Mavenu, postoji dobra, besplatna knjiga Better Builds with Maven koja se može skinuti sa Mergere sajta http://www.mergere.com/m2book_download.jsp

Moja iskustva sa mavenom su pozitivna. U mnogome ubrzava razvoj aplikacija. Naime, ako se radi o web aplikaciji (na primer), napravis osnovni kostur koji ces uvek koristiti za svaku web aplikaciju koju ces razvijati tako sto u pom.xml fajlu definises dependency-je, a onda te dependecies dopunjavas sa konkretnin jarovima. Odlicna stvar zbog toga sto ne gubis vreme da u svaku novu aplikaciju uvlacis fajlove te iz ovog direktoriju, te iz onog... Buildovanje aplikacije takodje ide mnogo jednostavnije...

Mavenovci, pomagajte!

Imam problem sa binarnim resourceovima. Naime, kada u resources folder stavim folder "slike" i untra spakujem neke jpg slike i odradim mvn package (jar modul), sve lepo prodje, ali su slike u jaru zabrljane!

Radio sam neko filterovanje resourceova, evo deo poma:



, pa sam mislio da ga to ne zeza, medjutim i kad sam totalno ukinuo resources iz poma, ista stvar se desavala, pa mi nije jasno u cemu je stvar, jel to neki bag ili sta?

Dakle, nije mi jasno zasto ne radi sa pomom koji ima ova podesavanja, jer sam lepo iskljucio filterovanje za slike, a drugo me interesuje zasto to isto ne radi i kada pom nema ova podesavanja, jer je pode defaultu filterovanje iskljuceno?

Sve mi smrdi na bag?

Pozdrav,
V

Aaaa, nije bag, sve lepo radi, problem je bio kada sam stavio slike koje su windows wallpapers :D

Pored pomenute knjige "Better Builds With Maven", nezaobilazna je i ova "Maven: The Definitive Guide":

http://www.sonatype.com/book/index.html

Nemojte me pogresno shvatiti - ne zelim da pokrenem neku "advocacy" diskusiju tipa Maven/Ant vs MAKE, ali recimo navedeni kod koji je jedan od ljudi poslao u prethodnih par postova se radi jednom jedinom linijom u Makefile-u. Onda kao covek koji i za JAVA projekte koristi MAKE postavljam pitanje - u cemu je poenta?
U tome sto Maven/Ant koriste XML koji je neki tehnoloski hype? Imao sam prilike (a u par navrata morao da koristim) Ant, i uvek sam se cudio da su Ant fajlovi bar jedno trostruko veci od adekvatnog MAKE fajla, a o kompleksnosti i citljivosti da ne pricamo.
Nakon lomljenja glave i pokusavanja da shvatim razlog za postojanje i popularnost Maven/Ant-a, dosao sam do zakljucka da je razlog prosto taj gorespomenuti XML, i cinjenica da komercijalna radna okruzenja mogu lepo bez muke da uvuku par stotina kilobajta Antovog XML koda i odrade sta treba.

Dolazimo do glavne poente - a to je da su oboje, i Ant i Maven, stvari napravljene za softver - programer nije sigurno lud da pise Ant kod rucno, niti to radi (da li iko od cenjenih JAVA programera sa ES-a pise Ant fajlove rucno???). - MAKE fajlovi se bez muke pisu rucno. Izgleda da je ideja da Ant ili Maven postanu neka vrsta standarda koji treba da bude podrzan od nekog radnog okruzenja, sto opet ne vidim da je istina, jer maltene sva veca okruzenja imaju neki svoj in-house sistem za bildovanje.

Vidi Leko, Maven je i nastao zbog toga sto su Ant skripte morale da budu glomazne da bi se odradio neki posao i zbog toga sto je Ant skripta za manje vise svaki projekat bila drugacija, a onda se radi copy-paste delova skripti.

Ono sto je najveca zabluda je da je Maven samo build sistem. Recimo, glavna stvar koja privlaci ljude ka Mavenu je dependency management sistem!

Sto se tice komentara za gore pomenuti XML, to je banalan primer. Maven dolazi do izrazaja kada se primenjuje na kopleksne JEE projekte na primer. Pogledaj kako izgleda "hello world" u Mavenu2 i shvatices da sam pomom od 15-ak linija (koji se btw AUTOMATSKI generise), mozes da izgradis strukturu projekata, da kompajliras kod, test kod, da uradis testiranje, da zapakujes jar, da odradis dependenecy menadzment, bez da brines o tome gde se nalaze biblioteke i artifakti, da deployujes tvoj artifakt! Takodje iz takve strukture, on the fly mozes da generises projektne fajlove za Eclipse, NetBeans, Ideau, a ako nema plugina za tvoj IDE (kao sto nema za ono sto meni treba), onda sednes, pa lepo sam napises plugin. Sa jos dve linije koda generises kompletan sajt projekta itd, itd.

Ima gomila stvari koje Make sigurno nema - artifakti, kontrola biuld lifecycle-a pomocu pluginova. Da ne govorim da postoji gomila pluginova za popularne stvari, ajde da dam jedan primer - imam XSD semu koja nije zakucana, znaci menjam je vremenom. Posle svake promene (posto korisim JAXB), ja moram da pokrenem rucno xjc kompajler da bih generisao java klase. Ok, moze da se napise skripta, nije problem. Ali to ce morati da uradi svaki programer. A pazi sad ovo u Mavenu - ja dodjem i kazem, ok ja cu da koristim Jaxb Maven2 plugin i samo je dovoljno da konfigurisem plugin sa 2 linije koda, gde kazem da modifikujem lifecycle tako da se u fazi generate-sources poziva odredjeni goal mog plugina koji odradi posao za mene. I cao.

Pored toga, postoji gomila podprojekata u okviru Mavena kao sto su Continuum, SCM, Wagon, Doxia i sl.

Maven je build sistem, dependency management sistem, repozitorijum, project management sistem, reporting sistem itd.

Znam da te nisam ubedio da je Maven dobra stvar, ali to je iz razloga sto sam ga i ja samo zagrebao. Nadam se da cu za nekih mesec dana moci da prenesem puna iskustva i odgovore na sva pitanja..

Mozda nije lose da citiram jedan deo knjige:

---------------------------
Maven... What is it?

This is a complex question, but a good one. Maven is a lot of things to a lot of people. If you use Maven to its fullest extent, it is a build and deployment tool vis-a-vis Ant, a dependency management tool like Ivy, a metric reporting tool, a documentation generator, a software project manager, a parent project, a build lifecycle, a project repository, a convention, a concept, and a community. A user may utilize one or many of these pieces, or use it for purposes hitherto undiscovered. At its core Maven is a framework for managing various aspects of a project, providing its own conventions and tools to meet this end and acting as glue for making existing disparate tools work in a tractable and orderly manner.
Convention over Configuration

Convention is at the heart of Maven. Convention over configuration is a popular aphorism these days, and Maven fully embraces this concept. Convention over configuration is at the central philosophy of frameworks such as Ruby on Rails, and more recently, the EJB3 specification. In its most basic sense it means that, while configuration is certainly necessary, the majority of users will never utilize such edge-cases those complex configurations provide. Although a powerful framework certainly needs to have the power to configure when necessary, it is certainly reasonable to create defaults to allow the 95% of similar use-cases to work without defining anything at all... the system can assume these defaults. In other words, the system has its own convention. Because of this, the monstrous configurations required of build tools like Ant (where a majority of Ant scripts are cut-and-pasted from existing projects) are non-existent for those projects that follow Maven's conventions.

Another driving force behind the popularity of convention over configuration is the speed at which new users may pick up a new technology, or the speed by which a seasoned user may begin using the tool without concerning him/herself with details that need not come up until later in the development process. The computer world is finally beginning to embrace the idea that ease of use and reduced configurations do not have to interfere with the power of advanced configurability. Convention and configuration reside together within the Maven world, each providing their own unique perspective of a power tool.
A Brief History of Build Tools

There are literally thousands of books, "collateral damage" if you will, filled with supposed "perfect solutions": perfect programming languages, perfect platforms, perfect IDEs, or perfect processes. But far fewer books cover the build tools that are often every bit as important as the languages themselves. Build tools have a historically under-appreciated symbiotic co-history with the programming languages and methodologies that they try to manage. Each has left its own indelible mark on the world of software development; some good (Make), some not so good (shell scripts). But along the way we have inched ever toward the ultimate goals of programming: ease of use, reusability, reliability, portability. Someday Maven, too, will be a footnote in this history adding another step to some unknown end. Until such a time, however, it is currently the best tool we have on our collective belt.

Make / Ant / Maven

In the beginning, there was no standard build tool. If one wanted to compile and link code, cave-dwelling developers were forced to input system commands with their own hairy-knuckled hands; this worked well as long as the whole tribe of developers knew all of the esoteric grunts and commands to make the build work. As their programs increased in complexity, however, it became immediately obvious such methods could be automated using simple tools.

As programming languages themselves have evolved, the focus of incremental improvements have centered on more than just readability and maintainability they were also developed to be more portable. C was a large improvement over previous languages (as was the operating system) in a large part due to its portability between different types of machines. But despite its undeniable success in this realm, machine architectures were largely diametrical, and system tools were incompatible by today's standards. Eventually, shells became more standard, and the ability to script common commands in a common language became more ubiquitous. This caused a new problem. Although a program was portable between machines with similar setups, computers would often contain different tools for completing the same job, such as a different implementation of the C compiler. Building code across various machines still proved rather painful. Enter: Make. Make was a marked improvement over shell scripting due to its abstraction of specific shell commands into a more general and consistent syntax.

Fast forward a few years to the birth of Java, a popular machine-portable programming language created to relieve the burden of cross-compilation by compiling to machine portable byte code. Now the machine-specific aspects of Make made the build tool even less portable than the code it was meant to build, in addition to other issues the frustrated Java developers (who are you to tell me where to put whitespaces?!), July 19 2000 birthed the first release of Ant as an independent build tool.

Ant is a pure Java build tool defined by XML syntax. Its ease of use and agility at extension made this seemingly simple concept explode to the de facto Java build tool in less than a year's time.
Why not just use Ant?

Ant is a great project. So was Make. However, they both suffer from the inherent weakness of the "Inner-Platform Effect" anti-pattern. The Inner-Platform Effect roughly states that by making a system too flexible and configurable, the configuration of the system itself becomes so complex it takes a specialist in order to maintain it - thus re-introducing the problem that the system was attempting to solve. Or in other words, the configuration becomes a platform itself, requiring all of the tools and special knowledge of any programming language... effectively creating a system in a system. For non-trivial projects Ant scripts can become almost as complex than the projects that they are required to build.

Ant is still an excellent tool, and is available as part of the Maven core collection of plugins - enabling you to create custom extensions out of existing Ant scripts, or even embed Ant directly into your project's build lifecycle (more on that later). Maven was created to deal with some of Ant's more egregious limitations. Firstly, the size of an Ant's build file directly correlates to its complexity. In short, the more things you want Ant to do, the larger the build file gets. This is due to the fact that Ant build files are procedural. A user must specify each step that the build system is to take. In Maven, due to its in-built conventions, there is a very good chance that your Maven configuration file will not grow at all (or at least, not grow very much) despite what you use it for because Maven configuration files are declarative. It is up to individual plug-ins and the Maven core to decide how to take action; you need only direct it with a modicum of information about your project.

Second is the question of portability. Ant is portable only if your users have the same set of tasks that you have. It is up to Ant's users to download and manage their own library of tasks, and it is expected that for any particular task, they know which tasks are required - as well as the correct versions. Oftentimes the most prudent method is to bundle the build tools along with the code to be built, which is hardly pragmatic (though problems of this nature can actually be rectified with Ant extensions like Ivy, which in all fairness, uses the Maven repository writ-large). Maven, on the other hand, deals with this problem natively and automatically, making portability effortless, and keeping even the largest teams in synch.
---------------------------

_{[Ovu poruku je menjao Vanja Petreski dana 10.06.2007. u 20:50 GMT+1]}

Ok, u tom slucaju autori Mavena su resili da (maltene) sve ono sto im treba za razvoj projekata strpaju u jedan paket i to nazovu Maven.
Imao sam prilike da koristim slicnu stvar za C/C++ razvoj (generise projekt/"solution" fajlove za VC++, KDevelop, kao i GNU Makefile-ove) koja se zove CMake (http://www.cmake.org) i mogu ti reci da nisam odusevljen. - Zasto? Zato sto kada imas vise ljudi koji btw. mogu da koriste dva razlicita okruzenja (koriste normalno sta vole), onda se normalno projekt-fajlovi za ta okruzenja razvijaju nezavisno i pretpostavljam da je nemoguce objediniti to nekim zajednickim sistemom. Maven u ovoj prici vidim samo kao pomoc nekoj osobi iz ekipe koja radi recimo "incremental builds", testiranje, itd., jer to moze sve da odradi (pretpostavljam) pomocu Mavena, bez koriscenja nekog okruzenja (dakle iz konzole).
Kazes da Maven ima neki "repozitorijum" - sta to tacno znaci? "Version control"? - Znas i sam da su programeri poprilicno tvrdoglava sorta i tesko sa nekog "omiljenog" VCS prelaze na drugi. :) Secam se svog prelaska sa CVS na SVN pre 6 godina, a takodje sam trenutno u rascepu izmedju Subversion-a i GIT-a koji smatram trenutno najboljim VCS sistemom, ali i dalje koristim Subversion. :)

Pretpostavljam da Maven daje siroke mogucnosti JAVA programerima, ali ja i dalje ne vidim razlog za neku masovnu migraciju.

PS. tvoj primer sa XSD semom i automatizacijom pravljenja JAVA klasa pomocu xjc je jako dobar. Recimo, ekipa programera koji koriste Subversion bi u tvom slucaju napisali Subversion "post-commit hook" (2-3 linije koda!), koji je zapravo obican skript (mozes da ga napises u bilo kom jeziku), a koji bi prosto pozvao xcj kada dodje nova verzija odgovarajuceg fajla. Verujem da svi moderni VCS sistemi imaju nesto slicno.

Hm, pa zapravo nije tako. Maven je u sustini vrlo prosta stvar - framework za izvrsavanje pluginova. Kada instaliras Maven ti nemas nista, imas samo jedan jar. On pri prvom pozivu napravi za usera koji ga koristi repozitorijum tipa ~/.m2/repository/ koji je manje-vise prazan u pocetku. Kada ja, recimo, prvi put pozovem komandu mvn compile, Maven shvati da ja nemam plugin compile (ovo je zapravo samo skracenica, pravo ime plugina je drugacije, ali to sad nije bitno). i onda ode na centralni Mavenov repozitorijum (pre je to bio ibiblio, sada je cini mi se repoX.maven.org ili nesto slicno) i skine taj plugin i smesti ga u lokalni repozitorijum. I tako za sve pluginove. Takodje, kada ja pravim nekakav modul nekakve aplikacije (modul se u Mavenu zove artifakt), ja ga onda "instaliram". To znaci da se moj artifakt smesti u moj lokalni repozitorijum. U okviru ovoga je potrebno videti poglavlje o kolaboracionom radu, jer je moguce da se druge Maven masine, kada shvate da nema artifakta u njihovom lokalnom, kace na druge Maven masine u potrazi za modulom (artifaktom). Tipicno postoji jedan centralni repozitorijum na mrezi koji cuva sve artifakte...

Dakle, jedna od poenta repozitorijuma JE DA SE NA VCS NE SMESTAJU BIBLIOTEKE (dependency)!!! O cemu se radi. Zamisli da imas projekat koji se izmedjuostalog sastoji od recimo 10 web aplikacija i svaka koristi spring i svaka, klasicnim putem bez Mavena, ima svoj projektni folder i, tipicno, folder lib gde drzi biblioteke, u ovom slucaju recimo Spring 1.X (odgovarajuce jarove). Ti ces onda na 10 mesta imati te jarove i na 10 mesta na VCS-u. I sad zamisli da sutra pozelis da predjes na Spring 2.x. Ti to moras 10 puta da menjas. Pazi kako to ide kod Mavena - ti u POM-u projekta (objektna definicija projekta) kazes da zavisis od Spring artifakta i preciziras verziju. To uradis u svakom pomu tvog projekta koji zahteva Spring. A poenta je sto, cak i da imas 1000 projekata koji koriste odredjeni artfakt kao zavisnost, ti imas u lokalnom repozitorijumu samo jednom taj artifakt (skup jarova, whatever), zavisnosti se NE kopiraju u projektni folder!!! Najlepsa stvar od svega je sto pluginovi za generisanje projektnih fajlova za IDE umeju da uradi sledecu stvar - podese putanju ka lokalnom repozitorijumu tako da ide u compile time-u zna gde tebi stoje te stvari. U Eclipsu je samo jednom potrebno podesiti promenljivu MAVEN_REP (ili tako nesto). No, da se vratim na primer - i sada u Maven varijanti price, ti zelis da svicujes na Spring2. Sada je samo potrebno da u 10 pomova promeni <version> sa 1 na 2. Automatski Maven skida Spring2 i cao. Nema prepodesavanja radnog okruzenja, nema kopiranja jarova x puta, sve se nalazi na jednom jedinom mestu - u lokalnnom repozitorijumu!



Ne Evo u cemu je stos - ideja je da ti strukturu projekta NE GENERISE IDE. Vec da struktura projekta bude standardizovana (convention over configuration). Zato i postoje pluginovi za IDE-e koji od takvog projekta (Maven strukture projekta) prave potrebne strukture koje zahteva IDE. Ti mozes u IDE-u da radis sta hoces, ali projektni fajlovi (kod, resources, itd) koje menjas ce se primeniti na sve koji rade na tom modulu (samo kod smestas na VCS). Takodje, lepota u svemu tome je sto za IDE-e postoje pluginovi za Maven (do sada smo pricali o Maven pluginovima za IDE). Dakle, u Eclipse-u mozes da pokreces Maven goalove i sve ostalo sto mozes iz konzole

Trik je u tome sto smo u Mavenu fokusirani na 2 stvari: projekat (POM) i goalove (akcije, ono sto treba uraditi). Mi opisujemo pomom nas projekat, govorimo od cega on zavisi itd. Na osnovu toga, Maven zna sta treba da uradi sa njima. Imamo kontrolu ciklusa. I to je nas projekat. Ko pominje IDE? Niko. To je samo nesto sto treba da ti pomogne pri radu. Ali to nema nikakve veze sa bildovanjem i organizacijom necega sto se zove projekat.



Kakve veze ima VCS sa ovim? Pa to je nesto sto je deo zivotnog ciklusa builda, a ne deljenja koda?! Zamisli da lokalno menjas XSD. i sad hoces da testiras lokalno, jos nista ne komitujes. Kada pokrenes BUILD (ne commit), on treba to da uradi za tebe, zar ne?



Ponavljam se - reci cu ti sta mislim za neko vreme..

Masovna migracija na maven je u opensource java svetu već odavno krenula, i tu nema šta da se priča.

Mi u firmi koristimo maven već više od godinu dana, i koristimo mnoštvo raznovrsnih opensource framework-a, i 90% njih uredno objavljuju nove verzije na mavenovim repozitorijumima, da ne spominjem da ga većina njih i interno koristi za sopstvene projekte.

I mi smo imali mnogo otpora prema menjanju starog dobrog anta, i sitne problemčiće na početku, ali već sada niko od nas ne može da zamisli da se vrati na njega.

Verovatno ću da ponovim ono što su Vanja i ostali rekli, ali konkretan primer govori više od teorije.

Cilj: podesiti okruženje za razvoj projekta koji koristi npr guice za dependency injection.

Ništa lakše!

1.) mvn archetype:create -DgroupId=com.mycompany.helloworld -DartifactId=helloworld

2.) Da bih koristila spring, editujem pom.xml i dodam dependency:
<dependency>
<groupId>com.google.code.guice</groupId>
<artifactId>guice</artifactId>
<version>1.0</version>
<scope>compile</scope>
</dependency>

- Ne zanima me gde je guice jar
- Ne zanima me koji su njegovi dependenciji, i šta mu treba da bi radio

3.) mvn eclipse:eclipse

- Napravila sam projekat za eclipse, sa svim pathovima.

4.) mvn clean install

Jar je gotov.
Sa tri otkucane linije u komand promptu, i jednim editovanjem pom.xml-a završila sam sve što mi treba, i mogu da radim.

- Imam sopstveni jar, i sve taskove koji su mi neophodni da testiram i bildujem aplikaciju, clean, compile, package, install, test, prepare-resources..

Maven sve skoro radi sam.
Nisam tražila nikakve skripte po internetu ili na hard disku, a kamoli pisala. Nema copy/paste, nema traženja i downloadovanja jarova, dilema oko verzija, čačkanja po dependencijima...


Hoću da predjem na guice 2.0?

To je najbolji deo:
Izmenim version na 2.0, mvn eclipse:eclipse apdejtuje projekat.

- Ne zanima me koji dependenciji su promenjeni u 2.0, da li je nešto izbačeno ili ubačeno, ne zanima me gde je novi jar.
Promenila sam jedan jedini broj!

Lepota..

Ovo je jako subjektivno gledište. Ja recimo nemam nikakav problem da napišem ant skript ručno, mada iskreno uglavnom radim tako što kopiram neki postojeći skript ili koristim template (ako radim u Eclipse). Sa Mavenom i nema neke potrebe da generišeš bilo šta pošto je pom.xml za prosečnu aplikaciju veoma jednostavan. S druge strane, make skript nikad nisam pisao i ne deluje mi preterano razumljivo. Sve je stvar navike, ali mogu sa sigurnošću da kažem da se prosečan Java/JavaEE programer daleko lakše snalazi u Ant-u/Mavenu nego sa make fajlovima.



Ne znam odakle ti ove informacije. Ant je odavno de-facto standard za razvoj Java aplikacija a u poslednje vreme to polako postaje i Maven. Radio sam u nekoliko firmi i na više open source projekata i uvek se za build koristio ili Ant ili Maven.

Uh, milina, sad ne moram da pisem sam plugin za JDeveloper :)

Direkt sa M2 user liste:



Zelite da napravite Jdev projektne fajlove, nema problema, stavite ovo u vas pom:



I samo opalite:

Souce Caboom :)

Malo samo da doprzim corbu kada je maven u pitanju

http://blog.labnotes.org/2007/...-how-we-cured-our-maven-blues/

Hvala Vanji i sanchi na iscrpnim objasnjenjima. Shvatio sam i prednosti (koje su bile uglavnom fokus ove diskusije) a i mane.

Sto se tice dejankr-ovog teksta/replike na ono sto sam napisao - slazem se da je moj tekst subjektivan i da se radi o pitanju ukusa. Elem, radije cu koristiti nesto sto znam/razumem, sto ne radi stvari potpuno automatizovano (mada to zavisi od toga kako napisem Make kod), nego zavisiti od necega sto radi automatski do trenutka kada nesto krene naopako a onda sesti i citati tonu dokumentacije kako rucno editovati XMLove od par stotina/hiljada linija. Iz mog subjektivnog ugla: lakse mi je editovati citljivi Makefile nego editovati XML djubre koje je btw. u 99% slucajeva automatski generisano. Razlog zasto ja i dalje gotivim Make je prosto sto isti radi sa svim mogucim programskim jezicima koje koristim (i/ili ne koristim).
Sto se dejankr-ve opaske u vezi "standarda" i sistema za build koje razna okruzenja koriste tice, tu nema sta da se diskutuje - i sam si (dejankr) rekao da su oboje vec standardi, tako da kapiram da je ono pitanje ("ne znam odakle...") vise bilo upuceno na to koja okruzenja ne koriste Ant... Ja sam u svom kratkom Java zivotu naisao na nekoliko takvih, no VERUJEM da su neke novije verzije "sredjene" tako da sada koriste Ant. :)


U svakom slucaju, Vanja je uspeo da me ubedi da makar probam Maven. :)

Osnovna ideja mavena je bila da se izbace velike, komplikovane i necitljive skripte i xmlovi.
pom.xml je standardan, uvek iste strukture, lako citljiv i razumljiv, i uglavnom mali.

Nema tu bogzna kakvog trazenja greske: tvoj plugin ili radi, ili ne radi, i to je to.
Mi smo imali slucajeve da nije postojao odgovarajuci plugin, i embedovali smo ant taskove, sto nije posebno komplikovano.

Editovanje xml-a se uglavnom svodi na dodavanje/menjanje dependencija, i eventualno dodavanje novih pluginova ako hoces da podesis neku stvar specificnu za tvoj projekat.



Mi smo imali identicne probleme sa continuos buildovima.

Maven interno koristi vise repozitorijuma za prikupljanje resursa, a nekad treba dofinisati i dodatne. Desava se da neki od njih nisu dostupni u vreme builda.

Dalje, ako se ne fiksira verzija pluginova, maven ce sam koristiti najnovije, koji opet sami po sebi nisu dovoljno stabilni, pa se desava da se sa potpuno dobre verzije koja se koristila prebaci na novu kojoj ili fale neke stvari, ili ne jednostavno ne radi kako treba.
Dalje, meni i dalje nije poznat ceo algoritam po kom maven odlucuje koju verziju kog internog jara koristi, i odakle je trazi, ali se ta informacija definitivno razlikuje u zavisnosti od toga koji repozitorijumi su mu dostupni, i meta podataka na njima, tako da se opet ponekad desavalo da zbog izmene verzija odjednom na pogresnom repozitorijumu trazi pogresan jar i ne moze da ga nadje.
Zavrzlama neopisiva...
Sve su ovo bili privremeni problemi, i nadam se decije bolesti koje su mozda vec i resene, ali su za nas bili jako neugodni, i ludeli smo.

Da bi se to resilo, prvo smo fiksirali sve verzije pluginova koje koristimo, da bi se resio "maven uncertainty principle". Ovo je prakticno eliminisalo probleme.

Ipak, da bi bili potpuno sigurni, poceli smo u interni repozitorijum (koji smo vec imali zbog licenciranih stvari koje koristimo) da kopiramo i "eksterne" stvari, i da koristimo samo njega, tj. overrajdovali smo "central" sa nasim.

Ako zatreba nesto novo, promenimo profil i dovucemo nove stvari. Ako sve prodje ok, instaliramo u nas repozitorijum, i zatim se vratimo na profil koji koristi samo nas interni repo.

Ovaj sistem radi savrseno vec nekoliko meseci.

Ne iskljucujem da je ovaj "buildr", ili nesto drugo alat buducnosti, ali posto ja sa mavenom nemam probleme koje je on opisao, nije me bas ubedio za pocetak.

Upravo zbog sličnih stvari ja i dalje više volim da radim sa Ant-om. Maven će u 90% slučajeva sasvim fino i elegantno da ti odradi posao, ali zbog onih 10% koje umeju da uzmu mnogo vremena i živaca ipak više volim da imam stvari pod kontrolom. To podrazumeva i da su mi svi jar-ovi od svakog projekata na CVS/Subversion, jer nikad ne znaš da li će najnovija verzija biblioteke X raditi sa bibliotekom Y.
Slažem se da je Maven mnogo više od build tool-a, ali meni uglavnom build tool samo i treba. Uzgred, Ant fajlovi više ne moraju da se pišu sa copy/paste i da budu veliki i nečitljivi, pošto možeš da importuješ druge build fajlove i samim tim sve zajedničke stvari držiš u jednom fajlu.

Slažem se da je OK da radiš sa onim što bolje poznaješ. Pogotovo ako radiš sam. Međutim, ako radiš u okviru neke firme sa drugim programerima, moraćeš da se prilagodiš onome što se tamo koristi. Iz mog iskustva, mala je verovatnoća da će to biti make (ako govorimo o firmama gde se koristi Java). Daleko je veća verovatnoća da će tamo koristiti Ant ili Maven. Takođe, siguran sam da ma koliko je make fajl tebi čitljiv, daleko veći broj Java programera se mnogo lakše snalazi sa XML-om. Pri tome, ja čak ne mislim da je XML jako dobar način za definisanje build logike (što je priznao čak i autor Ant-a).



Možda se nismo dobro razumeli. Kada sam pričao o okruženjima mislio sam na firme i timove gde se koristi Java, ne na IDE alate. A što se tiče IDE, stvarno ne znam ni jedan Java IDE (sad ih i nema više mnogo: Eclipse, NetBeans, JDeveloper, IDEA...) koji nema podršku za Ant. Maven je mnogo manje podržan ali i to se popravlja...

Samo da se javim posle par meseci :)

Ja sam obecao da cu se vratiti sa pricom kada bolje savladam ovu materiju.

Ispostavilo se da je znanje toliko naraslo da je prosto nemoguce u jednoj temi sve opisati, a da se to ne pretvori u pisanje knjige :D

Izucio sam i implementirao infrastrukturu baziranu na Mavenu i pratecim tehnologijama (Continuum, Artifactory, SVN...) i odradio 3 projekta u ovoj prici i mogu vam reci da sam odusevljen!

Drzao sam prezentaciju na ovu temu, a ona se prostirala na 3 dana po ~ 3 sata, pa mislim da je jasno zasto je nemoguce sve ovde ispricati :)

U svakom slucaju, ko se bavi ozbiljnim Java razvojem, definitivno vredi krenuti u ovom pravcu.

V

Bilo bi lepo ako bi u okviru JavaSvet-a održao predavanje na tu temu. Mislim da bi ljudi voleli da čuju takvo predavanje.
Java zajednica nije baš aktivna u poslednje vreme, treba je malo prodrmati.

Ako mi verujes da sam razmisljao o tome :)

Raspolozen sam, sta su koraci?

@Vanja
Mozes da kontaktiras Igora Spasica oko predavanja na nekom narednom sastanku JavaSvet zajednice
http://www.javasvet.net/kontakt.html
[quote]POTREBNI PREDAVAČI!!! Za predavanja su potrebni predavači. Jako smo fleksibilni po pitanju tema, sve što ima veze sa Javom, softverskim inženjerstvom dolazi u obzir.[/qoute]

Iskomunicirao sam sa Igorom. U procesu je pronalazenje adekvatne lokacije drzanja predavanja i potrebnih HW resursa. Bicete blagovremeno obavesteni o detaljima :)

Okvirno - kraj februara/pocetak marta.

Predavanje je 1. marta. Vise detalja na http://www.javasvet.net/sastanak/9/index.html

Ne znam da li ste primetili ali zadnjih par nedelja je baš prisutno "anti-maven" raspoloženje po raznim blogovima i forumima? Odjednom svi vide njegove mane! Evo u ovoj diskusiji ima dosta linkova ka raznim blogovima: http://www.infoq.com/news/2008/01/maven-debate

Meni RSS klijent pun toga u poslednjih 10 dana :D

S obzirom da imam dobro misljenje i mavenu, bas sam se pitao koje su mu lose strane.To sto nema dobrih pluginova za IDE? Moze se preci preko toga, ako to nekome toliko smeta, moze i sam da ih napravi, zar ne :)

nisam dosad cuo na neko koristi Ivy umesto mavena.

A to sto je neko mora da "read their manual everytime I want to creating a project"!
Pa ko kreira nove projekte svaki dan, da bi ka to smorilo ?!?

A nije problem napraviti i batch file koji pokrece
mvn archetype:create....

Ja sam naisao na nekoliko problema, mada ne toliko ozbiljnih.

Podrska za IDE: Sto se tice Eclipsa, situacija je losa, ima jedan kilav, a i Google je napravio jedan, ali je u raspadu. Medjutim, kod IDEA 7.0.2 situacija je kul. Idea sama prepozna Maven projekat i nudi mogucnost pokretanja goal-ova i faza na klik, sa sve outputom u njoj. Ono sto meni licno nedostaje u Idei je podrska sa searchovanjem odredjenog artifakta, a da plugin sam potrazi u definisanim repozitorijumima, ponudi izbor i da na klik sama azurira POM. Ovo postoji u Eclipse pluginu, ali su druge funkcionalnosti plugina lose. Idea takodje nudi importovanje projekata iz maven strukture (mada ovo nije neophodno posto sam maven ima plugin za ideu - idea:idea)

Dokumentacija - ovo jeste malo mucno, morate da kopate po netu ili po 2 vec malo neazurne i nepotpune knjige, ali boze moj, obicno se zadrzite na konacnom skupu funkcionalnosti koje razradite i to vam radi posao. Po meni, fali jedna valjana knjiga o ovome.

Meni licno najvise ide na zivce sto kada mi treba odredjena biblioteka, ja saram rucno po repo1.maven.org/maven2 i trazim artifakt. Nekad se ispostavi da se totalno zeznem. Na primer servlet-api artifakt se nalazi pod groupId servletapi.servletapi, ali i pod javax.servlet.servlet-api. Neretko se desava da odredjena (tipicno najnovija) verzija biblioteke (artifakta) ne postoji, pa onda moram da pribegavam rucnoj instalaciji artifakta u inhouse repozitorijum. Da ne govorim da tada moram rucno da specificiram zavisnosti te biblioteke od drugih. Ali dobro, ovo resavam "vestackim" pom projektom kao dependency grouping.

I na kraju, postoje neki sitni bagovi za koje mora da se ceka da dodju na red na JIRI. Primer: ako imate prepodesen central repo na vas inhouse, a nemate konekciju ka internetu sa vase masine (a imate vezu sa inhouse repom) i pokrenete archetype:create na lokaciji koja nema pom.xml (sto je prirodno) maven se blokira.

Vidim da se mnogi zale na to sto jedan build u jednoj situaciji se bilduje sa jednom verzijom plugina, a kod nekog drugog posle nekog vremena na primer, sa drugom i onda pukne. Pa se ovo resava tako sto se u pomu predefinisu verzije plugina, sto je mucno s obzirom da ima gomila pluginova. Ja licno sa ovim nisam imao problema. Nikad nisam razmisljao koja verzija plugina se koristi za nesto..

Ali kada se sabere i oduzme, mislim da se isplati :)

Iskren da budem, nisam imao dobra iskustva sa ovakvim pristupom, pa da idem na import maven project, niti da uzmem pa da kreiram novi preko new maven project (radim u eclipsi).. Razlog je taj sto UPROPASTI classpath. Dakle totalan disaster napravi. Tako ne mogu da na primer koristim posle TestNG plugin (recimo). Jedino pa da iskopiram .classpath fajl iz nekog drugog projekta.

Sam napravim 4 source foldera i dodam pom.xml i idem na enable maven. I tako sljaka ql

p.s. Idemo svi da slusamo Vanju u REXu!

Za potrebe firme, kao deo software arhitekture, a da bi i resili problem kreiranja novih projekata, kreirao sam nekoliko custom archetype-a (nazovimo ih maven template projektima).

Pokazalo se kao odlicno resenje problema pokretanja novih projekata i sredjivanja medjusobnih zavisnosti. Naravno, kljuc je u kreiranju sopstvenog lokalnog maven2 repository-ja (koji izmedju ostalog sadrzi i custom biblioteke).

Upravo i to ce biti jedna od tema predavanja - archetypes ;)

Što se ovoga tiče ne moraš ručno da pretražuješ:
http://www.mvnrepository.com/

isve je tu što ti treba.

Hm, ovo je skroz ql. Medjutim, izgleda da je ovaj search potpuno baziran na ibiblio-u? Ne znam zasto to vise nije oficijalni repozitorijum, cak je i u Artifactory repository menadzeru blacklistovan. Opet stoji problem ako se doda specifican repozitorijum, recimo JBossov. Jel si ti ibiblio postavio kao svoj central?

Uff.. prvo izvinjenje što ne odgovaram ovako dugo. Forum ne obaveštava po defaultu na mail :( a ja sam bio u gužvi proteklih dana pa nisam svraćao.

Ne znam odakle ti da ibiblio nije oficijalni repository? U suštini nikad nije ni bio. Koliko ja znam ništa nije baš proglašeno "oficijalnim" repozitorijumom (što mislim da je najveći problem mavena) nego svako može da podigne svoj i da preusmerava zahteve za bibliotekama koje na poseduje ka drugim repozitorijumima.
Ovo je u suštini dobro za firme. Npr. mi imamo podignut artifactory na kome se nalaze interne biblioteke a za dohvatanje "spoljnih" biblioteka postavljen je proxy repo na ibiblio i springov repo.

E sad loše je za opensource projekte kada svi krenu da prave svoj repo a ne skupljaju se biblioteke centralno i onda to napravi problem pri pretraživanju.

U principu ja koristim gorepomunit pretraživač kad god mi je nešto potrebno i to završava posao.

Maven je overall jako dobar samo što bi trebalo poraditi na centralnom repozitorijumu kako bi svima život bio još lakši.

Maven2 centralni repo je http://repo1.maven.org/, uvek bio, i na njemu su skoro sve biblioteke (ukljucujuci, recimo, springframework biblioteke).

jes tačno taj, a mvnrepository.com pretražuje isti.

U suštini jedino ako neko želi SNAPSHOT verzije biblioteka mora da doda specifične repozitorijume, ali opet to je ok.

Upravo tako. Dakle repo1 JE zvanicno oficijalni. Kako to? Pa ako pogledas id "central" tacno gadja repo1, dok ga ti ne pregazis (na artifactory, na primer). Doduse pluginovi se traze sa repo1 + sa codehausa, posto oni imaju gomilu pluginova (mojo.codehaus.org)



Ne znam sta ti vidis, ali ja sta god da ukucam kao query na gornjem sajtu, ja dobijem ibiblio.

Izvinjavam se. Tačno, moja je greška.

Kad sam odgovarao gledao sam šta mi stoji kao central, a pošto koristim mvnrepository za pretragu, nisam obratio pažnju da on pretražuje samo ibiblio. Nisam do sada naleteo na neku biblioteku koju maven nije uspeo da dovuče sa repo1 a da sam je našao na mvnrespotiry pa otud i moj gornji zaključak.

A za oficijalni repo, jes repo1 centralni, ali koliko sam ja našao nikad nije bio proglašen kao oficijelni.