Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

Jel koristi neko Maven?

[es] :: Java :: Jel koristi neko Maven?

Strane: 1 2 3

[ Pregleda: 14725 | Odgovora: 44 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

anon315

Član broj: 315
Poruke: 1657
*.antegra.com.



+13 Profil

icon Jel koristi neko Maven?03.11.2006. u 16:14 - pre 211 meseci
Voleo bih da cujem malo o Maven-u od nekog ko ga koristi.

Sta je, kako mu je pomogao, koliko je komplikovano skapirati ga i slicno?

V
 
Odgovor na temu

Java Beograd
Novi Beograd

Član broj: 11890
Poruke: 9445
*.eunet.yu.



+10242 Profil

icon Re: Jel koristi neko Maven?03.11.2006. u 21:27 - pre 211 meseci
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.
OTPOR blokadi ulica, OTPOR blokiranom Beogradu, OTPOR blokiranoj Srbiji
 
Odgovor na temu

anon315

Član broj: 315
Poruke: 1657
*.adsl.sezampro.yu.



+13 Profil

icon Re: Jel koristi neko Maven?04.11.2006. u 11:20 - pre 211 meseci
Citat:
Java Beograd:A možda je zamišljen da zameni ant ?


Hm, nisam bas siguran...

Citat:

Philosophy of Maven

Maven is generally considered by many to be a build tool. Many people who come to Maven initially are familiar with Ant so it's a natural association but Maven is not just a build tool, and not just a replacement for Ant. Maven is an entirely different creature from Ant. Ant is simply a toolbox whereas Maven is about the application of patterns in order to achieve an infrastructure which displays the characteristics of visibility, reusability, maintainability, and comprehensibility.

Without these characteristics it is highly improbable that multiple individuals will work productively together on a project. Without visibility it is unlikely an individual will know what another has accomplished and as such there is a very good chance useful code will not be reused. When code is not reused it is very hard to create a maintainable system. When everyone is constantly rooting around trying to figure out where all these different bits and pieces are that make up your project there is very little chance anyone is going to comprehend the project as a whole. As a result you end up with the silo effect, a decay of shared knowledge along with the commensurate degree of frustration among team members. A natural effect when processes don't work in the same way for everyone.

Maven was borne of the very practical desire to make several projects at Apache work in the same way. So that developers could freely move between these projects, knowing clearly how they all worked by understanding how one of them worked. If a developer spent time understanding how one project built it was intended that they would not have to go through this process again when they moved on to the next project. The same idea extends to testing, generating documentation, generating metrics and reports, testing and deploying. All projects share enough of the same characteristics, an understanding of which Maven tries to harness in its general approach to project management. On a very high level all projects need to be built, tested, packaged, documented and deployed. Of course there is infinite variation in each of the above mentioned steps, but this variation still occurs within the confines of a well defined path and it is this path that Maven attempts to present to everyone in a clear way. The easiest way to make a path clear is to provide people with a set of patterns that can be shared by anyone involved in a project.
 
Odgovor na temu

dejankr
Dejan Krsmanovic
JavaEE programer
Beograd

Član broj: 7842
Poruke: 384
*.sbb.co.yu.



+1 Profil

icon Re: Jel koristi neko Maven?04.11.2006. u 13:10 - pre 211 meseci
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.
 
Odgovor na temu

anon315

Član broj: 315
Poruke: 1657
*.adsl.sezampro.yu.



+13 Profil

icon Re: Jel koristi neko Maven?04.11.2006. u 14:24 - pre 211 meseci
Dejane, hvala na opsirnom odgovoru, mislim da sam uhvatio poentu

Svakako zvuci interesantno, potrudicu se da mu dam sansu!

V
 
Odgovor na temu

Toxter
NS

Član broj: 39393
Poruke: 317
*.ADSL.neobee.net.



+6 Profil

icon Re: Jel koristi neko Maven?04.11.2006. u 14:43 - pre 211 meseci
Citat:
dejankr: ... on mora da isproverava sve na Internetu što dosta usporava...


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!
Sad mu nije nista, ubio si ga k'o zeca...
 
Odgovor na temu

Java Beograd
Novi Beograd

Član broj: 11890
Poruke: 9445
*.eunet.yu.



+10242 Profil

icon Re: Jel koristi neko Maven?04.11.2006. u 20:00 - pre 211 meseci
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.
OTPOR blokadi ulica, OTPOR blokiranom Beogradu, OTPOR blokiranoj Srbiji
 
Odgovor na temu

dejankr
Dejan Krsmanovic
JavaEE programer
Beograd

Član broj: 7842
Poruke: 384
*.dynamic.sbb.co.yu.



+1 Profil

icon Re: Jel koristi neko Maven?05.11.2006. u 11:46 - pre 211 meseci
Citat:
Toxter:
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.


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.

Citat:
Toxter:
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.


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



Citat:
Java Beograd: dakle, maven je novi i malo drugačiji ant ?


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
 
Odgovor na temu

mikorkns
Software developer
Novi Sad

Član broj: 35748
Poruke: 26
*.static.sbb.co.yu.



Profil

icon Re: Jel koristi neko Maven?06.11.2006. u 13:05 - pre 211 meseci
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...
 
Odgovor na temu

anon315

Član broj: 315
Poruke: 1657
*.antegra.com.



+13 Profil

icon Re: Jel koristi neko Maven?17.05.2007. u 17:50 - pre 205 meseci
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:

Code:

<resources>
        <!-- Zelim da dinamicki filterujem resourceove, pa moram da stavim na true! (pogledati x.properties) -->
        <resource>
            <directory>src/main/resources</directory>
            <filtering>true</filtering>
            <excludes>
                <exclude>slike/**</exclude> <!-- NE RADI (TODO) -->
            </excludes>
        </resource>
        <!-- NASTAVAK - NE RADI (TODO) -->
        <resource>
            <directory>src/main/resources</directory>
            <filtering>false</filtering>
            <includes>
                <include>slike/**</include>
            </includes>
        </resource>
</resources>


, 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
 
Odgovor na temu

anon315

Član broj: 315
Poruke: 1657
*.antegra.com.



+13 Profil

icon Re: Jel koristi neko Maven?21.05.2007. u 07:49 - pre 205 meseci
Aaaa, nije bag, sve lepo radi, problem je bio kada sam stavio slike koje su windows wallpapers :D
 
Odgovor na temu

anon315

Član broj: 315
Poruke: 1657
*.antegra.com.



+13 Profil

icon Re: Jel koristi neko Maven?05.06.2007. u 15:28 - pre 204 meseci
Pored pomenute knjige "Better Builds With Maven", nezaobilazna je i ova "Maven: The Definitive Guide":

http://www.sonatype.com/book/index.html
 
Odgovor na temu

leka
Dejan Lekić
senior software engineer, 3Developers
Ltd.
London, UK

Član broj: 234
Poruke: 2534
*.paws.umds.ac.uk.

Sajt: dejan.lekic.org


+2 Profil

icon Re: Jel koristi neko Maven?10.06.2007. u 19:03 - pre 204 meseci
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.
Dejan Lekic
software engineer, MySQL/PgSQL DBA, sysadmin
 
Odgovor na temu

anon315

Član broj: 315
Poruke: 1657
*.adsl.sezampro.yu.



+13 Profil

icon Re: Jel koristi neko Maven?10.06.2007. u 19:30 - pre 204 meseci
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]
 
Odgovor na temu

leka
Dejan Lekić
senior software engineer, 3Developers
Ltd.
London, UK

Član broj: 234
Poruke: 2534
*.paws.umds.ac.uk.

Sajt: dejan.lekic.org


+2 Profil

icon Re: Jel koristi neko Maven?11.06.2007. u 13:46 - pre 204 meseci
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.
Dejan Lekic
software engineer, MySQL/PgSQL DBA, sysadmin
 
Odgovor na temu

anon315

Član broj: 315
Poruke: 1657
*.adsl-1.sezampro.yu.



+13 Profil

icon Re: Jel koristi neko Maven?11.06.2007. u 16:30 - pre 204 meseci
Citat:

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.

+

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.


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!

Citat:

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


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.

Citat:

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.


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?

Citat:

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


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

sanchi
Sanja Jokic
Beograd

Član broj: 148256
Poruke: 104
*.cisco.com.



+8 Profil

icon Re: Jel koristi neko Maven?11.06.2007. u 17:53 - pre 204 meseci
Citat:
leka:
Pretpostavljam da Maven daje siroke mogucnosti JAVA programerima, ali ja i dalje ne vidim razlog za neku masovnu migraciju.


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

If people were meant to pop out of beds we would all sleep in toasters.
Google is your friend http://justfuckinggoogleit.com/
 
Odgovor na temu

dejankr
Dejan Krsmanovic
JavaEE programer
Beograd

Član broj: 7842
Poruke: 384
*.dynamic.sbb.co.yu.



+1 Profil

icon Re: Jel koristi neko Maven?12.06.2007. u 20:15 - pre 204 meseci
Citat:
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.


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.

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


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.
 
Odgovor na temu

anon315

Član broj: 315
Poruke: 1657
*.adsl-1.sezampro.yu.



+13 Profil

icon Re: Jel koristi neko Maven?12.06.2007. u 21:32 - pre 204 meseci
Uh, milina, sad ne moram da pisem sam plugin za JDeveloper :)

Direkt sa M2 user liste:

Citat:

The Apache MyFaces community is pleased to announce its
1.0.1 release of the Apache MyFaces Trinidad Maven2 plugins.

These Maven2 plugins have been deployed to the Apache Maven2 and they
are mirrored by ibiblio as well.


release notes
Apache MyFaces Trinidad Plugins (version 1.0.1) (for JSF 1.1)

This file contains informations for the 1.0.1 release of the Plugins
for the Apache MyFaces Trinidad solved Jira issue:

Issues:
ADFFACES-487 - Change Component generator to us XXX.valueOf(x) instead
of new XXX(x) when converting between primitives to Objects in
components
ADFFACES-459 - maven-faces-plugin doesn't support deprecated element
in facet-metadata element
ADFFACES-412 - JSLocaleElementsGenerator cannot be parsed by latest
version of Qdox
ADFFACES-411 - xrts plugin should support metadata content
ADFFACES-406 - Tagdoc should list appropriate values if enumerated.
ADFFACES-372 - The Trinidad Maven JDeveloper plugin is not able to
handle multiple TLD files having the same name.


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

Code:

<build>
   <plugins>
     <plugin>
       <groupId>org.apache.myfaces.trinidadbuild</groupId>
       <artifactId>maven-jdev-plugin</artifactId>
       <version>1.0.1</version>
       <configuration>
         <libraries>
           <library>JSP Runtime</library> <!-- Ovo ce, na primer dodati library u vas projekat -->
         </libraries>
       </configuration>
     </plugin>
   </plugins>
 </build>

 <dependencies>
.....


I samo opalite:

Code:

mvn jdev:jdev
 
Odgovor na temu

Dejan Lozanovic
Dejan Lozanovic
Beograd

Član broj: 691
Poruke: 2325
*.dynamic.sbb.co.yu.

Jabber: null@elitesecurity.org
Sajt: speedy-order.com


+75 Profil

icon Re: Jel koristi neko Maven?13.06.2007. u 13:52 - pre 204 meseci
Souce Caboom :)

Malo samo da doprzim corbu kada je maven u pitanju

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

[es] :: Java :: Jel koristi neko Maven?

Strane: 1 2 3

[ Pregleda: 14725 | Odgovora: 44 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.