JUM IX.

Egészen sokan gyűltünk össze tegnapelőtt a Számalk épületében. Az első eladás a Maven-ről szólt Verhás István tolmácsolásában. A gyors közvéleménykutatás alapján jelenlévők nagy százaléka használ Ant-ot, kis része Maven-t is, Ivy-vel pedig egy ember foglalkozott.

Ahelyett hogy az előadást részletezném inkább leírom a saját fogalmazásomban bullshitek nélkül, hogy miért érdemes Maven-t használni Ant helyett:

-Ant esetén a függőségeket (egyéb jar-ok) a verziókontrollba szoktuk pakolni. hogy ne kelljen mindenkinek kézzel összevadásznia. Ez azért aggályos, mert ezeknek függőségeknek a mérete elég nagy magához a forráskódhoz képest. Fölösleges branch-elésnél kópiát készíteni belőlük, fölösleges minden egyes archiválásnál elmenteni őket. Ha több projekt ugyanazokat a jar-okat használja, fölösleges többször letárolni őket. Gyorsabban fogy a DAT kazetta, gyorsabban pusztulnak az esőerdők. Update 2009.06.21: Kommentekre is reflektálva, természetesen nem az a Maven elsőrendű célja hogy takarékosabb legyen, ráadásul ahogy megtudtam az internetes Maven repository-k elég sok téves/fölösleges letöltési kérést kapnak, úgyhogy megint csak rosszul jönnek ki a dologból szegény fák a nagyobb hálózati forgalom miatt. Viszont ha valaki internetes sourcecontrol-ba akarja tenni a forráskódját, pl. Google Code vagy SourceForge, oda tényleg nem szerencsés betenni a függőség jar-okat, mert egyszerűen elfogy a kvóta.
-A projekt kialakításakor a függőségeket készzel kell összevadászni. Ha ezt a jar-t használom akkor kell ez is meg emez is, és akkor melyik verzió is kellene?
A Maven megoldást ad erre azzal, hogy csak a függőségek nevét kell megadni, amit letölt magától a kapcsolódó egyéb függőségekkel a netről egy lokális repository-ba a gépre. Sőt, ha kell letölti a függőségek függőségeit ügyelve a megadott verziószámokra. Ha már egyszer letöltött valamit, nem megy újra neki. Szoktak használni vállalati repository-t is: ilyenkor a fejlesztők Maven-jei nem közvetlenül az internetről szedik le a jar-okat, hanem a vállalati repo-ból. Ilyen pl. az Archiva. Update 2009.06.21: Ahogy a legutóbbi Eclipse DemoCamp-en Jason van Zyl előadásán megtudtam, a Nexus az a repó menedzser amit igazán érdemes használni. Így csökkenthető a forgalom, növelhető a sebesség, ráadásul saját privát "artifact"-okat (=termék: jar, war, ear, ilyesmi) is fel lehet oda tenni. Az előadó szerint vállalati repó nélkül gondok szoktak lenni a Maven használattal komolyabb környezetben, pl. ha egy artifact-ot kézzel kell letölteni, mert privát vagy a licenszelése miatt nincs fenn publikus repo-ban a neten.

-Ant esetén ki szokott alakulni egy szilárd build.xml és könyvtárstruktúra mindenféle projekt őstípushoz, pl. webalkalmazás, J2EE alkalmazás, amit aztán csak mindig gépiesen másolgatunk az új projektekbe és átírjuk a könyvtár és projekt neveket, esetleg beleírunk egyéb extra task-okat. A build.xml igazából fölösleges is, csak azt kellene tudni hogy ez milyen őstípus és mivel akarjuk kiegészíteni.
A Maven pont ezt csinálja. A pom.xml-ben csak azt kell leírni, hogy miben térünk el az eredeti őstípustól (archetype), pl. használunk valami saját annotáció feldolgozó eszközt. Ugyanitt kell megadni a függőségeket is. Őstípust pedig roppant egyszerű létrehozni. Íme egy példa egy Wicket alkalmazás létrehozására. Egy parancssorból letölti a szükséges jar-okat, megcsinálja a könyvtárstruktúrát, buildel, csomagol, futtat teszt üzemmódban saját Jetty szerverrel, itt most éppen Eclipse projektet csinál csatolt böngészhető Wicket javadoc-cal és forrással. Ez azért nem rossz nem?

Ezenkívül tud még javadoc-ot csinálni, sőt szabványos szájtot is tud generálni a projektnek. Ez a titka az Apache és Sourceforge oldalakon található Built with Maven matricáknak. Még annyi, hogy a hivatalos Maven oldalon rengeteg a bullshit és általában szeretik nagyon túlmisztifikálni a dolgokat, de van egy elektronikus könyv Better Builds With Maven címmel, ami egy nagyon hasznos olvasmány. Mert attól hogy automatikus build eszköz, a projektgazdának nem árt érteni hozzá.

Mondták még nekem a Gradle-t ami egy még újabb build eszköz. Ahogy néztem ez valóban procedurális, mint ahogy az Ant nem az. Egyelőre nem fog meg hogy script-eket írhassak buildeléshez, mint a régi szép időkben.

Második előadás Verhás Pétertől SOAP tesztelésről szólt. Nem ez az álmaim melója, de ha muszáj akkor fel kell majd keresni a SOAPui, a Greenpepper és a Confluence honlapját. A SOAP tesztelés abból áll, hogy lapáttal hányjuk be az XML-eket egy fekete színű doboz bal oldalán, majd a jobb oldalon kijövő több tonnányi XML-t nagyítóval nézzük át. Nem árt ha ehhez van némi integrált júzerbarát környezet ami tudja mi az a WSDL és a táblázatban leírt tesztadatokból SOAP üzeneteket generálgat, valamint zöld csíkokat rajzolgat.

A harmadik előadás Viczián Istvántól az adattárházakról: A Prezi-t használta a bemutatóhoz, ami nagyon kúl volt! A blogján elvileg fog ebből írni egy cikket, úgyhogy nagyon nem is megyek bele, csak bevezetem: Ha egy -alapesetben adatbázisban lévő- adattömegről dinamikusan változó igények alapján riportokat, kimutatásokat szeretnénk csinálni hisztorikus módon (akkor is ha az eredeti adatbázisban az adatok nincsenek hisztorikusan tárolva), akkor a kerék újrafeltalálása helyett esetleg érdemesebb az OLAP (Online Analytical Processing) megoldások felé kacsintgatni. Gyorsan belátható, hogy egy ilyen feladathoz speciálisan felépített adattárolásra van szükség: Ritkák az update-ek, sokféleképpen kell indexelni, előre aggregálni kell adatokat hogy gyorsabb legyen a lekérdezés, nem igazán jellemző a tranzakionális, sokfelhasználós működés. Nem biztos hogy SQL a legalkalmasabb lekérdezési mód, sőt lehet hogy nem is relációs adatbázis az optimális tároló eszköz! Az adatokat tudni kell összesítve megjeleníteni, lefúrni a részletekbe, más szempontok szerint megjeleníteni. Erre vannak kész -leginkább fizetős- eszközök. Sajnos az előadás hamar véget ért időkorlát miatt, de még az is lehet hogy a következő JUM-on lesz folytatás. A cikket pedig kíváncsian várom!

Ismét volt videózás, de azt nem tudom hogy az elaőadások hová és mikor lesznek feltöltve. Következő alkalom pedig május 20.