Mercurial paranccsor alapok

Egyszer már írtam erről a verziókezelőről. Azóta inkább az SVN felé sodort az élet, de most ismét elővettem ezt a remek eszközt. Az online könyv, amit a múltkor említettem még mindig megtalálható, csak az URL változott: Mercurial: The Definitive Guide by Bryan O'Sullivan.

Egy-két alapkoncepció, amit a könyvből tudtam meg:

• Minden fejlesztő gépén van egy history-t tekintve teljes mélységű saját repository. Egy repo-t létrehozhatunk kézzel, de leklónozhatunk egy másikat. Amikor becsatlakozunk egy projektbe, tipikusan leklónozunk valami központi szerveren lévő repo-t. (Mert központi szerver azért itt is lehet.)
• A projekten belül a .hg könyvtárban vannak a Mercurial dolgai, a többi mind a miénk, nem szemetel bele. Ez utóbbit hívják 'working directory'-nak.
  
• A branch-elés nem egy kitüntetett művelet, hanem minden egyes revízió gyakorlatilag egy új branch-pont. Az előző ponthoz visszakanyarodva: tetszőleges revíziót le lehet klónozni, nem csak az utolsót.
• A commit csak a saját repo-ba teszi be a változtatásokat (hg terminológiában: changeset). A push paranccsal lehet kiküldeni a változtatásainkat központi repo-ba és a pull paranccsal lehet behozni másik változtatásait.
• Kétféle revízió azonosító van: egy szigorúan monoton növekvő természetes szám ami csak lokálisan érvényes és egy hexadecimális azonosító, ami globálisan érvényes az adott repo-ban. A szám azért nem lenne elég, mert nem biztos hogy minden repository klón ugyanazon az úton, ugyanannyi változtatással jut el egy állapotig. A hexa kódra kell hivatkozni tehát, ha másokkal kommunikálunk.
• A .hg/hgrc fájlban vannak az adott lokális repository-val kapcsolatos információk.

Van egy futó Maven projektem, amiből akarok csinálni egy Mercurial repo-t. Beállok a projektkönyvtárba és kiadom hogy hg init, majd pedig azt, hogy hg add, felsorolva a repo-hoz hozzáadandó könyvtárakat és fájlokat. Pl. a Maven projektem esetében: hg add src pom.xml. (Maven-nél az src könyvtárban van minden forrás, a pom.xml pedig a buildeléshez szükséges információ. Vannak még egyéb könyvtárak is, pl. target, de azt nem kell a repo-hoz adni.) Végül pedig hg commit.

Ilyenkor feljön egy szerkesztőablak (nálam notepad) amibe beírhatom a commit comment-et. A szerkesztőablakban HG prefix-szel ellátott sorokban eleve látható néhány igen hasznos információ, pl. hogy mely fájlok változtak. A HG-s sorok a comment-ben nem lesznek benne. Ha nem írok semmit, a commit nem fog megtörténni.

A commit-oló user-t egy fallback mechanizmus alapján találja ki. A legerősebb megadási mód, ha -u kapcsolót használok a parancsban és explicite megadom. Meg lehet még adni a hgrc fájlban és a lánc legvége, amikor a bejelentkezett felhasználó nevét használja.

A hg tip mond információt a legfrissebb revízióról (a tip Mercurial terminológia), a hg log pedig history-t írja ki. Satöbbi. A hg help kiírja a lehetséges parancsokat, a hg [parancs] help pedig az adott paranccsal kapcsolatos tudnivalókat.

De mi van ha meggondolom magam és mégsem akarok Mercurial-t használni? Kitörlöm a projekt home-ból a .hg könyvtárat (esetleg előtte kiadom a hg revert -ar 0 parancsot ami visszaállítja a working directory-t az eredeti állapotba, majd egy commit-ot) és kész. Nincs szemét sehol máshol, mindenféle alkönyvtárakban.

Azért mégiscsak írogatok az Eclipse pluginekről is:

A HGE Eclipse plugin is megvan még amit a múltkor próbálgattam, de már átköltözött a SourceForge-ra, összenőtt a MercurialEclipse nevű pluginnel és MercurialEclipse néven fut tovább. Ja és mellesleg az Intland fejleszti, aminek erős magyar gyökerei vannak. Amikor installálom a plugin-t az Eclipse-be, be lehet jelölni hogy Windows binaries-t is hozzon le. Ha nincs külön installálva Mercurial akkor érdemes, mert azt később fel lehet venni a path-ba (az eclipse/plugins könyvtár mélyén van egy közönséges Mercurial disztribúció) és ha a plugin zavarba jön, lehet kézzel kiadni parancsokat. Nekem szükségem is volt rá mindjárt az első kanyarban.

JavaFX Eclipse kipróba

Kitaláltam hogy beleszagolok a JavaFX-be.

javafx.com a hivatalos kiindulóoldal ahol vannak csilivili demók, de engem a rögvalóság érdekel, úgyhogy utánanézek mit kell letölteni ahhoz hogy én is tudjak ilyen szépségeket programozni. Ezt az oldalt találom, ami azt mondja van SDK, Eclipse plugin és a downloads-okra visz. A Netbeans is támogatja, de nekem most nem az van kéznél.

JavaFX Installálás: Kicsit le voltam már maradva a java verzióval is. Mondja hogy JDK6u13+ kell. Letölti, installálja 5 percig. Felhoz SUN regisztrációs oldalt, de nem kell tölteni. JavaFX install gyorsabb. Alapból Program Files-be akarja installálni (ja mert Windowson vagyok), de átállítom. Nem történtek nagy dolgok szerencsére, megjelent a Start menüben, plusz az install helyen. bin könyvtár, ilyesmik.

Eclipse plugin:
update site: http://javafx.com/downloads/eclipse-plugin/
Verzió: 1.2.0.20090528....
Az ajánlott 3.4.2 ganymede-re installálom néhány másik plugin mellé, mint pl. m2, SVN, WTP, Findbugs.

Sikerül az install. Új projekteknél megjelenik a JavaFX projekt. Néhány prototípusból tudok választani. Fotónézegető, 3D-s polc megjelenítő. A Spring (pattog két labda) példát választom - fordul, működik. Ha az lenne a célom, játszhatnák vele hogy változtatgatom itt ott a kódot, de most nem ez a célom. Lehet új külön JavaFX fájlot létrehozni, megjelenik a JavaFX perspektíva és egy külön Run opció a futtatáshoz.

Viszont nem túl komoly a támogatás.

Jobboldalt van egy Drag and Drop-os komponenskészlet kevés komponenssel, de grafikai szerkesztés nincs, csak bedobja a kódrészt ész nélkül oda ahova viszem az egérrel, akkor is ha szintaktikai hibát eredményez. A context assist működött egy darabig, de rövid használat után elromlott, azóta csak ClassCastException-t hoz fel az IDE újraindítása után is. A javafxdoc hover működik, de nekem nem tetszik a formátuma. Túl nagy betűk, ha böngészőben nézem szerencsétlen az elrendezése. Folyton scrollozni kell le-fel, le-fel, le-fel.

Egy egyszerű Swing-es GUI-t akarok átültetni próbaképpen JavaFX-re, ismerkednék a layout-okkal. Alapkövetelmény lenne, hogy az ablak tartalma némileg intelligensen kövesse az átméretezést. Ez Swing-ben igen egyszerű a BorderLayout vagy a GridBagLayout segítségével. Negatív meglepetés: nagyon gyér a layout támogatás. Ráadásul régebbi verziókhoz képest sokmindent visszavettek. Pl. nem lehet GridBagPanel-ozni. Ráadásul a túl sok változtatás miatt, a net tele van használhatatlan példákkal.

Találok egy ígéretes layout menedzsert, DigLayout néven. Letöltöm a jar-t, hozzáadom a projekthez, de nem reagál rá, nem találja meg az osztályt hiába importálom. No ez már azért kicsit durva, úgyhogy be is rekesztem a kísérletezést.

A nyelv maga az oké. A szintakszis kicsit a JSON-ra hajaz bár semmi köze hozzá. Tetszik a deklaratív megközelítés, és látom hogy sok szépet és jót lehet csinálni vele -és bízom benne hogy egyszer majd fogok is- , de egyelőre a 2-3 órás ízlelgetés után, ebben a formában "nem vettem meg".

Kódlefedettség-mérés

A jtechlog-ban volt egy írás a code coverage-ről ahova be is böfögtem egy kommentet. Na most én is írok róla.

Az Emma is egy ilyen kódlefedettségmérő eszköz, ami mindenféle riportokat tud csinálni XML és HTML formában. De én nem szeretek build scriptből és command promptból bűvészkedni ha kódlefedettséget akarok nézegetni, szóval beérem az Eclipse plugin változatával, az EclEmma-val. Europa környezetben használtam eddig és most felraktam a Gánymedvére is (by czimi). Azon is megy szépen.

Tud package, osztály, metódus, blokk és utasítás lefedettséget. Szépen fában jeleníti meg és lehet nyitogatni, odaugrik a kódra ha klikkelek, valamint kiszínezi a kódot, szóval meg lehet nézni hogy mi hajtódott végre teljes egészében és mi részlegesen végül mi az ami kimaradt a szórásból. El lehet tenni régi riportokat, előszedni de ezt sosem használtam. Be lehet jelölgetni a kapcsolt jar-okat, hogy azoknak is mérje a lefedettségét. Az EclEmma-s honlapon van screenshot, több infó.

Node mire jó ez?

Legalapvetőbb célja az lehet, hogy a unit tesztek a kód hány százalékát hajtják meg. Első közelítésben ez egy szám ami nem sokat mond. Kényelmes test driven fejlesztésnél nálam 70-80 százalék jön ki. Fel lehet tornázni 95, sőt 100%-ra is, de ez már néha igen sok melóval jár, főleg a szoftver határai közelében (I/O). Mindenféle mock-okat kell csinálni, le kell tesztelni mi a helyzet, ha egy stream close() metódusa elszáll IOException-nel, le kell tesztelni az UnsupportedEncodingException-t akkor is ha statikusan megadtuk az encoding-ot. (Checked exception, de minek.)

Akkor kezd izgalmassá válni a dolog, ha megnézzük hogy miért nem 100%, miért csak 70, elkezdjük lenyitogatni a fát, látjuk hogy egyes metódusoknak 0% a lefedettségük. Ilyenkor érdemes megnézni (CTRL+ALT+H) a metódus fordított hívási fáját, azaz hogy használja-e egyáltalán valaki. Nem használja, akkor meg miért van ott? Ha szükséges lesz az a metódus a jövőben akkor érdemes rá valami tesztesetet írni, hogy legyen valami contract-ja, ha nem akkor pedig ki lehet törölni. Ezzel is javul a lefedettség.

Más esetekben a metódusokon belül nem hajtódnak végre bizonyos ágak. Igazi TDD-nél ennek nem nagyon szabadna előfordulnia, de ha mégis akkor pótolni kell a hiányosságot mihamarabb.

Ad hoc tesztelésről feltornázni a teszt lefedettséget -próbáltam- egy rendkívül unalmas és szélmalomharcnak tűnő feladat. Az eredmény sem lesz olyan jó, mintha már az elejétől folyamatosan készülnének a tesztesetek. Update: De TDD nélkül is használható egy ilyen eszköz. Ilyenkor tesztesetek nélkül, egyszerűen azt kell megnézni, hogy némi működés -némi kattintgatás- után a program mely részei kapnak vezérlést. Az összes funkción végigzongorázva a holtággá vált kódrészeket végülis ki lehet így szűrni, egy adott funkció megpendíténél pedig meg lehet találni kilóra hogy a funkció a kód mely részeit hajtja meg.

Másik, nem túl triviális célja annak jelzése, hogy az összes teszt lefuttatása során a tesztkód hány százaléka fut le. Ennek 90-100 százalék közelében kell lennie. Ha ennél alacsonyabb akkor vagy ki vannak ütve tesztesetek -amit illik megindokolni- vagy valamiért nem kerül bele az összes teszteset a suite-be, vagy a tesztkód szerkezete nem megfelelő. Unit teszteknél nem szabad körmönfont vezérlési szerkezeteket használni, nem elfogadható hogy egy adott teszteset kódja nem fut le teljes egészében (100%). If-nek például elvileg egyáltalán nem szabadna tesztkódban lennie, legfeljebb utility osztályban. Egyébként az 5-10 százalék veszteség is valószínűleg a utility osztályokban kell hogy legyen.

1-2% veszteséget a lefedettségmérő eszköz is csinál mérési hibaként. Majd ideírom amikor megint találkozom vele, de úgy emlékszem a finally blokkban lévő kódot nem számolja, valamint az inicializáló blokkokkal is mintha meggyűlt volna a baja. Szóval a 98-99 százalékot néha lehet 100-nak venni már.

Reverse engineering-nél lehet érdekes azt megnézni, hogy egy adott teszteset vagy adott funkció a kód mely részeit hajtja meg. Ránézésre látni kilóra, hogy mely package-ek osztályok és metódusok kaptak vezérlést, miket érdemes a későbbiekben figyelemmel kísérni. Nekem hasznos volt ez a felhasználási mód is néhány alkalommal, amikor más kódjával ismerkedtem.

És végül amiért most ismét elővettem ezt az eszközt: 3rd party komponensek lefedettségét is meg lehet vizsgálni. Éppen egy webstart alkalmazáson dolgozom hobbiszinten, ami használ egy-két külső könyvtárat, de csak egy-két funkció erejéig. Az egyszerűség kedvéért az egész hóbelevancot egy jar-ba csomagolom és arra gondoltam ki fogom ütni a nem használt osztályokat a külső könyvtárakból a buildelés során. Most 1.3 mega a jar, jó lenne lemenni a harmadára. Bár az az érzésem hogy van erre jobb céleszköz is.

Egy-két régi Ant-os projektünket is szívesen végigbogarásznék egy ilyen lefedettségmérővel, mert ott már a világ összes jar-ja benne volt a lib könyvtárban. A Maven-nel már más a helyzet, mert az már ügyel a függőségek kezelésére -mondhatná egy Maven-hívő- de azért ott sem ilyen egyszerű a kép. Néha azért csattogtatni kell a exclusion-okat, mert pl. a log4j-hez is összeszed minden szutykot amit nem is akarok használni.

Remélem sikerült lefednem a kódlefedettségmérés felhasználási lehetőségeit. Jó pénteket!

JUM 09.01.21

Ismét konf. beszámolót írok, de azért nem cél a témára való teljes rácuppanás. Nézzük csak: a tegnapi Java User Meeting a Számalk épületében kapott helyet, ami a hazai számítástechnika 20-30 évvel ezelőtti temploma. Az épület emiatt inkább hasonlít egy ódon főiskolára mint egy modern irodaházra.

OSGi

Az első előadás az OSGi-ról szólt, ami egy dinamikus modularizációs keretrendszer (óeszdzsíáj, ezt mindig le akartam így írni, hát most tessék). Talán legközismertebb működő példa az Eclipse, ami ilyen alapokon fut, ugyanis a benne használt Equinox is egy OSGI implementáció.

Volt rövid elméleti bevezető aztán gyakorlatiasabb demó. Egy Eclipse-ben láthattuk először egy HelloWorld bundle (így nevezik az alapegységet) létrehozását nullából, aztán némileg összetettebb példák működését. Kb. úgy lehet létrehozni mint egy plugin-t, tehát new project, ... és ki kell választani hogy nem Eclipse hanem standard OSGi környezetben akarjuk futtatni. Ha jól sejtem nem árt ha benn van az IDE-ben a Plugin Development Environment installálva. A rendszer classloader filozófiája elég kifinomult, emiatt lehetőség van verziózott modulfüggőségek megadására a megfelelő helyeken - azt hiszem a manifest fájlban. Meg lehet adni verzió intervallumokat, egy környezetben működhet többféle verzió is egy adott egységből, satöbbi. Nekem úgy tűnt, hogy ez hasonlít a .net Assembly kezelésére. Felmerült egy kérdés, hogy ez vajon kiküszöböli-e a "bundle-hell"-t, a bundle függőségek összekuszálódását, hogy pl. a log4j-t beteszem a saját bundle-mba hogy ne váljon külső függőséggé. Ha értelmesen használják akkor kiküszöböli. Megemlítették, hogy van Maven plugin vagy bundle vagy mi, ami magától lehozza a szükséges függőségeket. (Van valakinek linkje, tapasztalata erről?)

A bundle-eket lehet futtatni, próbálgatni az IDE-n belül. Kapunk egy OSGi konzolt, amin különböző parancsokat bepötyögve tudjuk elindítgatni, leállítgatni és monitorozgatni a különböző bundle-okat. Hasonlít egyébként a Windows service-ekre első ránézésre: ott figyelnek a bundle-ek, vannak állapotaik miszerint el vannak indítva, installálva vannak de nincsenek elindítva, illetve az installálásuk nem sikerült teljesen. Némi infó még itt.

Volt szó eseménykezelésről, ami első látásra hasonlít a JMS-re, viszont lényegesen lightweightebbnek tűnik.

Az előadók elmondása szerint jobban bejön nekik mint alkalmazásszerverek és J2EE/EJB-k használata, mert egy ilyen OSGi konténer nagyon hamar - a másodperc törtrésze alatt - újraindul, kevés gond van vele. (Hát én azért vállalati alkalmazásoknál eléggé meg vagyok elégedve az EJB3-mal, szóval ezek után még nem váltanék. Megbecsülöm az EJB appszerver admin konzolokat, realm és resource konfigurációs szolgáltatásokat amiket egy-egy appszerver ad.) Szó volt még Spring integrációról, de ez enyhén szólva nem hangzott jól. A bundle-n belül van applicationContext vagy a bundle-k vannak egy nagy applicationContext-ben benne, vagy a kettő egyszerre? Kínzó kérdés.

Adobe Flex

Cornel Creanga az Adobe bukaresti irodájából jött el evangelizálni. Az elején megijedtem, hogy a mainframe-ektől indul az előadás, de szerencsére hamar eljutottunk a Flash-ig és annak jelentőségéig. A demók mindenképpen meggyőzőek voltak, de nagy bánatom hogy nincsenek Flash és az erre épülő Flex fejlesztéshez ingyenesen használható eszközök, csak az Eclipse alapú Flex Builder. Említésre került az AIR, ami egy desktopos flash futtatásra alkalmas platform Webkit alapokon.

A számunkra legérdekesebb dolgok az előadás végén hangzottak el a java integráció kapcsán. Alapvetően a Flash HTTP, SOAP és mindenféle socket alapokon tud kommunikálni a szerveroldallal, de van lehetőség olyan elérésre, ami a JavaScript JSON mechanizmusához hasonlóan automatikusan elvégzi a távoli metódushívásokat és az eredmények továbbítását a szerverről a kliensre. Van hibernate integrációs szerveroldali komponens, ami gondoskodik a kliensről leküldött objektumok megfelelő perzisztálásáról.

Demózásra kerültek olyan használati esetek, amikor a szerver push-olja az adatokat a kliensre, vagy amikor egy A kliensen átírt adatok rögtön megjelentek a B kliensen reload nélkül (kliens = web böngésző). Láttunk példát Flash pdf dokumentumba való beépítésére is. Talán a legfontosabb, hogy van egy Tour de Flex példaalkalmazás amit érdemes lehet nézegetni. Elvileg sok érdekes példát tartalmaz.

Kaptunk egy mini O'Reilly könyvet Getting Started With Flex 3 címmel. Villamoson való olvasgatáshoz tökéletes.

Előadások után elmentünk páran a Bajor Sörözőbe a Móriczra, ahol egyszer ki kell próbálni a sztrapacskát. Megbeszéltük a nagy nemzetközi helyzetet Cornel-lel. Náluk is Microsoft-ot használnak az állami szektorban, a bundáskenyeret bundáskenyérnek hívják és így tovább.

A legközelebbi JUM alkalom márciusban lesz, ahol jó lenne behajtani a most elmaradt JPA 2.0-t. Többször is elhangzott az a szó, hogy Groovy és hogy többeket is érdekelne egy ezzel kapcsolatos eszmefuttatás.

Eclipse Democamp

Ezúttal egy VIII. kerületi vendéglátóipari helyen került sor az Eclipse Democamp-re a b2i szervezésében. Még nem voltam ilyen rendezvényen eddig, de nagyon meglepett a baráti, unconference jellege. Rögtön meg is kérdezték ki vagyok és akarok-e valamit előadni, de nem volt semmi érdekes a tarsolyomban. Magamhoz vettem némi búzasört.

Az első demóban arról volt szó, hogy EMF (Eclipse Modeling Framework) segítségével összerakunk egy modelt (a konkrét példa egy CD adatbázis volt), GMF (Graphical Modeling Framework) -fel pedig csinálunk neki egy grafikus szerkesztőfelületet, amin egy osztálydiagramhoz hasonlóan lehet szerkeszteni a modelt természetesen Eclipse környezetben. Belül a GEF (Graphical Editing Framework) -t használja a program.

Hozzáértő kezek között 10-20 perc alatt össze lehet rakni egy ilyen bonyolultságú modelt és a szerkesztő felületét. Találkoztunk egy-két buggal a demózás közben, amivel viszont nem árt tisztában lenni. Mit mikor kell újrafordítani, újraindítani. A szerkesztett alkalmazás természetesen egy másik Eclipse példányban fut amit minden iterációs körben nem árt újraindítani -bár lehet hogy ezt meg lehetne úszni valahogy. Elmondásuk szerint 6 hónap alatt raktak össze egy komplex egészségügyi adatokat közvetítő rendszert a GMF betanulással együtt. A modell maga nem kell hogy java legyen, köztes típusokat használ.

Ha konkrétan ilyen feladattal találkoznék akkor mindenképpen megfontolnám az eszköz használatát.

Második előadásként a FOT-os srácok mutatták be a teszt framework-üket amit már jópár éve használnak banki alkalmazások tesztelésére. A dolog lényege hogy Eclipse környezetben futtatják a teszt szekvenciákat. Van a banki felületet -a teszteléshez szükséges minőségben- leutánzó GUI, részletes (zöld, sárga, piros) fa/log jellegű eredmény megjelenítés, riport küldési lehetőségek. Ha jól értettem egy bizonyos middleware rendszer tesztelésére csinálták, amit viszont néhány bankban aktívan használnak. Szintén ha jól értettem, közeli-távoli terveikben szerepel, hogy ne csak ezt a konkrét middleware rendszert lehessen vele tesztelni.

A harmadik rögtönzött előadásban Eclipse tippekről és trükkökről volt szó, azaz kedvenc billentyűkombinációkról, funkciókról. Úgy láttam hogy ezen a téren elég kiműveltek az emberek, a jelenlévők között majdnem mindenki ismert már majdnem minden trükköt.

Elvileg nagyjából fél évente van ilyen rendezvény. Megpróbálok elmenni a következőre, tovább maradni, többet cimbizni és esetleg előadni valamit.

A nagy konferencia persze idén is kimarad -ezúttal saját megfontolásból- de majd szorgalmasan olvasom az élménybeszámolókat.

Mercurialozom

Ideje volt már feltennem a sajátgépemre egy elosztott verziókezelő rendszert. Miért is? Saját használatra Windows-on nem akartam CVS-t vagy SVN-t izzítani, viszont a fejlesztőkörnyezet history szolgáltatása elég Mórickás, ráadásul lehet hogy más is be fog csatlakozni a fejlesztésbe. E írás alapján a Mercurial mellett döntöttem. Dióhéjban: git-re nincs Windows támogatás, Bazaar nem rossz, de a Mercurial mégiscsak ismertebb.

Írás még róluk a Javaworld-ön. Összegyűjtve dolgok még a JHacks-en.

1 perc múlva már ott figyelt az installált Mercurial 1.0.1 verzió a Windows-os gépemen.

A 3.3-as Eclipse-hez pedig lehúztam egy plugint.
E levél szerint Zingo Andersen fejlesztgeti pár éve szabadidejében.
Először nem működött valami jól, mert nem tudtam visszanézni a régi verziókat, de végül uninstall után a béta update site-ről szedtem le a legfrissebbet, ami már jól működik. Az ikonok dekorálását explicit be kell kapcsolni a preferences label decorations-nél. Itt van a plugin fejlesztői oldala, itt van a béta update site URL-je is.

http://home.zingo.org/trac/mercurialeclipse

Megvan az SVN-ből vagy CVS-ből megszokott kellemes funkcionalitás. History, diff, annotation. Ezeket használom én, amikor verziókontrollozok. Persze a commit, update és társain kívül.

De van másik plugin is: Merclipse.
Ezt is kipróbáltam, de 5 perc után leszedtem, mert elsőre nem állt kézre a funkcionalitás. (Valami vagy nem működött, vagy nem találtam meg és nem volt jól ledokumentálva hogy hol keressem.)

Team - Share Project-tel lehet varázsolni hamar a meglévő projektből Mercurial repositoryt. Aztán még add-olgatni kell a fájlokat és kommit-olni. Anélkül hogy ismerném a belső működését kijelenthetem, hogy a verziózott fájlok a projektben a .hg könyvtárban kerülnek eltárolásra. Nem szemeteli össze az összes könyvtárat mint az SVN vagy CVS, csak a gyökeret.

Hogy hogyan kell több gépet együttműködésre bírni azzal egyelőre nem foglalkoztam.

A következőn gondolkodtam el: mivel nincs központi repó és minden fejlesztő gépén fenn van a teljes anyag, elvileg nehezebben vesznek el az adatok. Viszont ha tönkremegy valaki vinyója és senki más nem szedte le az aktuális változtatásait az gáz. (Tapasztalt DVCS júzerek cáfoljanak meg ha nincs igazam.) Szóval elosztott rendszer ide vagy oda, mégiscsak jó ha rávésődnek az adatok egy-két masszív központi vasra is. Nyilván meg lehet oldani valahogy.

Mivel egyelőre saját célra használom egyedül, kiélvezhetem a commit comment-ek és a branch-ek előnyeit, de gondoskodnom kell róla, hogy néha kiírjam a repót CD-re vagy valami hasonlóra.

A Selenic-es Wiki-ben volt egy link egy nagyon jó ingyenes elektronikus könyvre, de már nem él: http://hgbook.red-bean.com/hgbook.pdf

(Zárójelben megemlítem hogy most háromféle verziókezelő plugin működik aktívan az Eclipse-emben gond nélkül. Ebből a Mercurial és a CVS egy workspace-en belül van, de úgy emlékszem az egyéb kombinációk is jól működtek eddig.)

Különben pedig valóban. Amíg intraneten SVN-ezik az ember addig mindegy, mert jönnek az adatok mint az olajozott villám, de ahogy pl. mostanában rákapcsolódtam egy távoli Google-s SVN trunk-re https-sel kicsit kényelmetlen lett hirtelen a sebesség, vagyis annak a hiánya. Intraneten néha passzióból history-t nézek vagy compare to-zok. Távoli trunk-on már jobban meg kell gondolni van-e fél percem és sávszélességem ilyen műveletekre. Szóval ja: hasznos lehet az elosztott verziókezelő néhanapján.

Eclipse J2EE támogatás

Kipróbáltam az Eclipse 3.3 J2EE edition J2EE alkalmazás támogatását. Nem nagyon találtam róla épkézláb leírást és csak 1-2 órányi kísérletezés után sikerült kitalálni, hogy milyen sorrendben kell csinálni a dolgokat és tulajdonképpen mi micsoda. A help-ben sokminden van, de egy lényegretörő leírás nincs, hogy "figyelj, így kell összerakni egy móricka-szintű J2EE alkalmazást", ezért most lepötyögöm ide.

Figyelj, így kell összerakni egy móricka-szintű J2EE alkalmazást:

Először is az Eclipse J2EE edition támogatja appszerverek vezérlését az IDE-n belül. Glassfish V2-t választottam játszásra, ami alapból nincs a támogatott szerverek között, de le lehet tölteni a modult. A konzol view-eknél van egy új fül Servers névvel. Lokális és távoli szervert is fel lehet venni, én lokálban próbálom. Gyakorlatilag elindítani és leállítani tudja a szervert, nem veszi észre a fenn lévő alkalmazásokat és ha Eclipse-n kívül indítom el akkor is zavarba jön. Azt hiszi hogy nincs elindulva és nem találtam olyan funkciót amivel frissíteni lehetne az állapotot - pedig nagyon meg tudnám becsülni. Szóljon aki tud ilyet! Ezen kívül megjelenik az appszerer logja egy konzol ablakban. Ja igen és debugolni is lehet az enterprise alkalmazást.

Leírom nagyjából hogyan néz ki egy ilyen J2EE alkalmazás belülről. EAR-ban vannak JAR-ok, WAR-ok és különböző XML-ek. (EAR, WAR, JAR: kb zip formátum.) Ezt kell bedobni az alkalmazás szerverbe. Ezenkívül lehet külső kliens, ami sima Java, csak még gondoskodni kell egy közös osztálykönyvtárról ami a külső kliens és az Enterprise App közti interfészeket tartamazza. Ez tipikusan egy jar, ami a kliensnél és a szerveren is megvan az EAR fájlban.

Csináljunk J2EE alkalmazást!

New J2EE application project
Target runtime, configuration - maradhat default, de később is még felajánlja. EJB3-as alkalmazást akarok csinálni.
J2EE modules to add - ha vannak más moduljaink. Generate deployment descriptor - csekkeljük be jól jön az.
Van itt egy olyan gomb hogy New module. Érdemes megnyomni mert rögtön felajánlja hogy csináljon-e client, ejb, web és connector modulokat. Engem most a web és a konnektor nem érdekel, azt nem csekkeltem be.
Rögtön létre is hozza a két projektet. (XXXEARClient, XXXEAREjb) Az EAR kliens alatt az én értelmezésemben pl. egy desktop alkalmazást értek *, ami cseszeregteti az EAR-t. JUnit teszteknek kiválóan alkalmas.
Finish. Megcsinálta az EAR-t is, átváltódunk J2EE perspektívába. Ha jól látom nem csinált szabványos ejb-jar-t, -hiába ikszeltem be- csak sun-ejb-jar-t.

Az EJB projekt context menüjében a J2EE menüpont alatt ki lehet választani a create EJB Client jar-t. Ezzel létrehozunk egy újabb projektet, amiben az EJB interfész osztályait tároljuk: business interfészek, kliens és szerver között mozgatott adatszerkezetek, utility osztálok kerülnek ide. Az EAR kliens projektben a J2EE module dependencies-ben be kell állítani, hogy lássa az EJB kliens projektet.

Új EJB3-at csak kézzel lehet létrehozni jelenlegi tudásom szerint.

-Az EJB kliensbe kell felvenni tehát egy interfészt ami a lokális vagy remote interfész lesz. Alaphelyzetben az ejbModule a forrásfolder. Tessék egy business interfész:

public interface ISample51 { //51: ötödik próbálkozásom első interfésze
String helloWorld();
}

-Az EJB projektben új osztály létrehozása Session Bean-nek. A felajánlott interfészeknél láthatóak az EJB kliensben létrehozott interfészek. (Ha elkezdjük írni.)
-Implementálni kell a metódusokat és fel kell annotációzni az osztályt pl. így: @Stateless @Remote public class SLSB1 implements ISample51 { ... } Azért remote, mert az appszerveren kívülről szólítjuk meg.
-Csinálni kell egy kliens osztályt. Már lehet hogy csinált egy Main-t a default package-be, ezt is használhatjuk. Egy ejb megkeresés és hívás így néz ki, ez kerül mondjuk a main belébe:

javax.naming.Context ctx = new javax.naming.InitialContext();
ISample51 hw = (ISample51)ctx.lookup(ISample51.class.getName());
System.out.println(hw.helloWorld());

Ha most futtatjuk a kliens osztályt jól elcsattan NameNotFoundException-nel, mert nem találja a bean-t. Miért is találná, nem deployoltuk. Ha nem lett volna elindítva az appszerver indítsuk el az Eclipse-en belül. Servers fül, play gomb. Deployoljuk: server view, context menü, add and remove project. Átnyomjuk az EAR projektünket a bal oldalról a jobbra, finish. A konzolon egy rövid Ant log jelenik meg. Nálam átlagos gépen 7 másodpercig tart a fenti bonyolultságú alkalmazás telepítése. Ha mindent jól csináltunk hibaüzenetek nélkül ÉS "Application Deployed at..." üzenettel. Vigyázat, ha valójában nem sikerült a deploy, akkor is képes kiírni a deployed üzenetet. Ha most futtatjuk a kliens osztályt, akkor már csinálja a dolgát.

Változtassunk bele az EJB-be minimálisan, buildeljünk újra. Ilyenkor az alkalmazás automatikusan újradeployolódik.

Ha az automatikus buildet beállítjuk, akkor kb. minden mentésnél megtörténik az újradeploy, ami nem valami szerencsés úgyhogy ezt az opciót érdemes kikapcsolni. Vannak még további lehetőségek is a build-deploy kapcsolatban, de ez most ezen a szinten nem érdekes.

Ha az interfészt megváltoztatjuk mondani kell egy olyat az EJB projeknek (a context menü J2EE részében) hogy update EAR libraries. Úgy emlékszem hogy bizonyos beállítások mellett erre nem volt szükség. Igen: Az EJB projektben a J2EE module dependencies-ben ki kell ikszelni a client-jar projektet.

* A Wizard által generált EARClient nem biztos hogy az aminek gondoltam, mert ha beleváltoztatok az maga után von egy újradeployolást. Márpedig ha a külső klienset változtatom miért kellene újra deployolni a szerver alkalmazást? Inkább csináltam egy új sima java projektet a külső kliensnek, amibe beimportáltam a J2EE library-t és felvettem függőségnek az EJBClient projektet. Így már jobban működik.

Dióhéjban ennyi. Közben még találtam egy hasonló -képekkel is illusztrált- leírást itt, JBoss-hoz. Ha pedig kinyitom a csapot, az jön belőle hogy hogyan kell Netbeans-szel Glassfish alá J2EE alkalmazásokat csinálni. Homokozásra jó ez az Eclipse-be integrált módszer, de semmiképpen nem ajánlanám komolyabb alkalmazások fejlesztéséhez. Többször is okozott meglepetéseket az IDE ha véletlenül összekavartam a dolgokat, pl. nem volt hajlandó buildelni. Tekintve hogy integrált buildelésről volt szó, nem tudtam mit csinálni csak találgatni vagy új workspace-t nyitni. Ant-os fejlesztésnél ilyenkor megjavítom a build scriptet és kész. Az Eclipse-ből kiemelve a projektek használhatatlanok, mert nincs bennük semmiféle build script. Próbáltam így importálni külső J2EE projekteket igazán kevés sikerrel. Ha már itt tartunk meg kell említeni a Maven plugint, amit viszont lehet használni komolyabb J2EE alkalmazásokhoz és a hierarchikus Maven projektek importálása is kiválóan működik.

A javalistán is éppen lett egy hasonló témájú thread az elmúlt napokban, konkrétan JBoss-ra kihegyezve.

Breaking News

• Nemrég kijött az Eclipse 3.4M2.
• Jó kis meccs van az Index fórumon a Java topikban Checked vs Unchecked exception témában. A javafórumon is megvolt ez a téma június környékén, de nem ennyire intenzíven.
• Van még mit írni a logokról, (MDC, log4j-logBack-Jsr47-JCL-jslf4j) csak most sok a meló.

Eclipse, Taconite

Hohó, két post egy nap alatt!

Szóval először is felraktam ma az 1.5-ös Firefox-ot aminek a Clear Private Data funkciója nagyon tetszik.

Kipróbáltam a Taconite-ot is ami szintén megfogott, csak kissé kényelmetlen volt highlight support nélkül jsp-ket írni, úgyhogy nekiálltam Eclipse plugin-t keresni. Találtam is, a WTP -t. Namost ha ennek csak a webes részét installálom akkor a jsp-ket nem highlight-olja hanem csak a html-t, css-t, xml-t meg még egy-két dolgot. A másik, hogy nem akarta az igazságot ezért installáltam gyorsan egy 3.1.1.-es Eclipse-t. Itt már működött, viszont kellett még hozzá installálni vagy 3 plugint. (JEM, EMF meg ki tudja mi...)

Most próbálgatom. Tetszik, már össze is haverkodtak a Taconite-tal. Highlight-ol mint a kisangyal, jönnek fel a popupok a lehetséges dolgokról, úgyhogy lehet haladni ezerrel. Egyetlenegy kis bánatom van, hogy nem támogatja a 4.0-ás JBoss-t. Ha J2EE projektet akarok csinálni 3.2.3 a legfrissebb amit ismer, és a projektcsinálás meg is bukik egy ponton amikor nem találja a jboss-boot.jar-t.

Közben volt egy downgrade-elés 3.2.6-os JBoss-ra és ismét megpróbáltam J2EE projektet létrehozni ugyanekkora sikerrel. Ennél régebbi JBoss-t már nem vagyok hajlandó feltenni. Generikus J2EE projektet is megpróbáltam létrehozni, akkor meg az annotation engine-be kötött bele, merthogy XDoclet-et szeretett volna. Azt hiszem az XDoclet már eléggé kifutóban van a JDK5 annotációi miatt úgyhogy ebbe már fölösleges (újra) belekezdeni. Akkor inkább megvárom a következő (rendes) verziót ebből az Eclipse pluginből.

Import static

Azt hiszem néha fogom használni az 5-ös java statikus import funkióját. Meg lehet mondani pl., hogy import static java.lang.Maths.*; vagy statikus metódusnevet. Ésszel hasznos, amikor hatszázszor ki kéne írni egy osztály nevét amiből egyébként csak statikus tagokat használok. CTRL-Shift-O -ra (importok rendezése) az Eclipse a kézzel beírt import static ...*-ot lecseréli a valóban használt tagokra.

Subclipse

Eclipse/külső verziókövető használat mellett megesik a package explorer-be épített "delete" funkció használata, ha egy fájllal kapcsolatos utolsó módosításaimat nem akarom bekommitálni. Namost integrált verziókövetőnél (SVN) ezt jobb ha elfelejtem, mert szépen halkan a repositoryból is töröl (nem fizikailag és véglegesen). Ez bizonyos esetekben persze kényelmes -ha direkt ez a cél. Még szerencse hogy van a "revert" funkció. Egyébként tetszik a subclipse plugin, szépen ki lehet dekorálni hogy mikori verzió, ki a szerző, stb.