Ami egy kicsit is megközelíti a Maven2 képességeit, is ANT-ra épül az az IVY. Jelenleg az Apache inkubátorában pihen, és egy remek jó dependency tool. Mivel ANT-ra épül nagyon jól be lehet passzintani mindenhová (pl. Netbeans, ami kezd jó ANT-ra épülni), ahová Maven2 plugin nincs is. Az API-ja is ígéretesnek tűnik, ki lehet cserélni jól a dependecy kezeléstől a latest verzió algoritmusig elég sok mindent. Ráadásul félig meddig kompatibilis a Maven-nel (pl. tudja olvasni az ibiblio-t).
Csakhogy ez idáig egy dependency management rendszer, és semmi több. A Maven2-t azért szeretik az emberek (vagy: ha szeretik, azért :) mert a definiált konvenciókkal sokkal egyszerűbb minden (erre múltkor volt egy frappáns angol kifejezés), azaz, ha mindig ugyanúgy buildelek, akkor érdemes ezt a részt csak egyszer megírni, és nem mindig implementálni ANT-ban.
Eddig oké. Természetesen ezt meg lehet csinálni IvY+ANT párossal is. Az ANT-nak elég jó API-ja van, az IVY szállítja a csomag és függőség kezelést. Csak azt kell elérni, hogy a letöltött csomagokban lévő osztályok integrálódjanak az ANT-ban (ezt nem lehetetlen), és azok rögtön beleszóljanak az api-ba. Így elérhetjük előszőr is, hogy a szokásos ANT taskok (pl. compile, jar, stb.) sehol se várjanak alapértelmezett paramétert, hanem mondjuk ahelyett valami magic propertyt használjanak. (Szimplán leszármaztatjuk az ANT taskokat), a magic propertyket meg előrde definiáljuk, ez lesz a konvenvió.
Sőt, azt is el lehet intézni, hogy alapértelmezett targetek legyenek (pl. compile, run, deploy), amik az ANT fájlban ugyan nincsenek benne, de meg lehet őket hívni a scriptből. (Feltéve, hogyha a csoda ivy+ant dolgunk a classpathban van). Meg mondjuk azt is megengedjük, hogy az alapértelmezett compile parancsot is felüldeifinálja a user, ha ő mindig más compile-t szeretne.
Ez szép, de akkor mi a kérdés? Hát az, hogy ilyen rendszer nincs. Jelenleg ugyanis Maven2 van, és mindenki (akinek van egy kis esze) azt használja. Amit felvázoltam arra lehetne egy Proof-of-Conceptet írni, de jelenleg nincs ilyen. Márpedig egy nemlétező program architektúrájáról előadást tartani meglehetősen öncélú dolog. Vagy fogom magam, és megírom az egészet, és tényleg komolyan veszem, és fegyverkezési versenybe kezdek a Maven2-vel (sok munkaórát beleölök), vagy hagyom az egészet. Ebben az esetben viszont elég felesleges előadást tartani egy olyan konkrét termékről (a konkrét termékről szól előadások már gyanúsak), ami nem is létezik, csak létezhetne, tehát a hallgatóság részéről gyakorlati haszna semmi nincs. (Kivéve egyetlen trükköt, hogy hogyan lehet automatikusan azzal definiálni ANT taskot, hogy egy jar-t bedobunk a classpath-ába). Sokkal inkább értelme van, egy létező dolog bemutatására konkrét tapasztalatokkal (vér, veríték).
Hát ezért bizonytalanodtam el, hogy érdemes-e megtartani a Maven2-es JUM előadás ANT-os párját. Mert ha az szólna valamiről nem az ANT-ról szólna, mert az egyértelműen nem ellenfele a Maven2-nek (Ezt egyébként a Maven oldal is igyekszik tisztázni, hogy ez nem csak egy másik build tool, hanem valami több annál). És amiről szólna, olyat meg úgy se fog használni senki.
Szerintetek?
Feliratkozás:
Megjegyzések küldése (Atom)
10 megjegyzés:
Hat, ket toolt objektivan osszehasonlitani marha nehez. Foleg ha ebbol a kettobol az egyik nagy favorit az eloadonal. Ellenben en szivesen vennek egy maven a gyakorlatban bemutatot. Esetleg egy olyan kis laza sessiont, ahol parhuzamosan lehet bemutatni, amit az egyikben igy lehet megcsinalni, azt a masikban hogyan. Igaz ez egy kicsit for dummies kategoria lehet, es nem az a kalapaccsal a billentyuzetet szetveros eset, de imho sok ember meg antot se nagyon hasznal, es biztos jol jonne nekik egy ilyen kis bemutato. De lehet, hogy nem. :)
Jaja, aki leter a kitaposott utrol a fejlesztesi processzben, az a pokol tuzen fogja vegezni :) A maven nelkul is, de maven meg tesz ra egy jo nagy lapattal :)
Jo az uj skin!
Skin: Köszi, túl hosszúakat írtam, muszály volt szélesíteni. :)
A dilemmám meg pontosan az volt, hogy érdemes-e belemenni egy absztrakt elméleti kérdésbe (hogy kéne csinálni jó kis build toolt ANT-ból), ha csak elméleti marad, és semmit nem profitálunk belőle.
zmb mintha azt sugalná, hogy inkább kézzelfogható dologra lenne igény, és nem szellemi tréningre...
Azert ismerek en arra peldat hogy az ant-bol szabvanyos build rendszert csinaltak, valami olyasmit mint a maven.
Izgi volt, eleg sok ember dolgozott rajta a cegnel, magyarorszagon azt hiszem 3, Oroszoknal legalabb 6-8. Innen most mar azt is tudjatok melyik cegrol van szo :-D
dilemma: engem akkor is erdekel, ha csak elmeleti iranyt mutatsz, esetleg hogy kik es hogy hasznaljak az ivy-t.
A kik és hogy egy nehéz probléma.
A havi incubator reportban ez van:
http://wiki.apache.org/incubator/April2007
Top three items to resolve:
Growth of commiters - We are still only two commiters, which is not enough to ensure the future of Ivy
[...]
Growth of community - We have a pretty active user community, seeing more with more involvement in the project would help.
Szóval még jócskán kell evangelizálni.
De meggyőztél, és akkor nekifeszülök. Szerinted belefogunk férni ketten együtt a 15-20 percbe? Vagy két külön előadás? (Ez talán már túl sok lenne)
Szerintem en siman beleferek 5 percbe :) Szoval a maradek 15 ha eleg neked, akkor meg benne vagyunk a keretben.
Este atkuldom neked a slide-okat amiket csinaltam.
Ok, köszi, 15 az sok is, mondjuk max 10. Rapid meccs lesz, legalább lesz idő a kérdésekre.
Dilemma: IMHO jo gondolat lehet valamennyire osszevetni a ket eszkozt, hogy egy problemat hogyan old meg. A masik, ami meg jol johet, bemutatni, hogy melyik eszkoz milyen feladatokra lett megalkotva, hol van a hataruk, mi az amire mar nem alkalmasak.
zmb: kössz, ez jó gondolat. Lehet, hogy össze is rakok majd egy feature matrixot ANT, IvY, Maven2 viszonylatban.
Megjegyzés küldése