jTechnics

Maven vs. scripting

Saturday, March 14th, 2009 | Uncategorized | No Comments

Van egy régi félkész projekt, ami az előző munkánkból potyogott ki, mint újrahasznosítható alkatrész. A központi része egy absztrakt adatbázisséma reprezentáció Java osztályokból. Ezt az absztrakt fát fel lehet építeni többfajta forrásból (pl. Oracle DB connection alapján leképezi egy meglévő DB felépítését, vagy egy Jar-t megadva leképezi a Jpa entitások által meghatározott sémát az absztrakt adatbázis sémává). Természetesen az absztrakt DB sémát ki is lehet iratni (célszerűen mindenféle adatbázis specifikus SQLé). Illetve egy eszköz meg tudja mondani két sémadefiníció különbségét, és azt is le tudja képezni SQL parancsokká.

Mire jó? Mi két dologra használtuk. Egyrészt a JPA osztályokból előállítottuk azokat a fájlokat, amikben az SQL parancsok voltak, amivel a sémát fel tudtuk építeni. Ez már csak a Unitils-es teszt környezetünk miatt is kellett, ami, ha érezte, hogy az SQL-ek megváltoztak, a teszt adatbázist rögtön törölte, és felépített egy teljesen új adatbázist. Másrészt a fejlesztési adatbázist is tudta frissíteni, mert beolvasta a jelenlegi sémát (Oracle system táblákból), és az új sémát (JPA osztályokból), összehasonlította a kettőt, és a különbséget SQLben mondta el. Így a fejlesztési adatbázist (és akár az éleset is) tudtuk inkrementálisan frissíteni, úgy hogy a meglévő tartalom ne vesszen el.

Most jön a lényeg. A projektet kicsit kipofoztam múltkoriban, és már ott tartok, hogy csináljak hozzá ANT taskot és Maven plugint. Azon gondolkoztam, hogy hogyan tudnám a konfigurálhatóságot úgy megragadni, hogy az egyes elemeket bármilyen párosításban lehessen használni. Bárhonnan tudjak sémát beolvasni (létező Oracle vagy Mysql séma, JPA osztályok), és bármit meg tudjak velük csinálni (Mysql vagy Oracle specifikus kiiratás, összehasonlítás különbség számítás).

Arra gondoltam, hogy a legrugalmasabb az lenne, ha nem az XMLen kéne erőszakot tenni, hanem mondjuk valami scrip nyelvel lehetne megfogalmazi, hogy mit akarok, és milyen összetételben.Az első tesztek szerint a JSR-223 teljesen jó megoldást adna, mindenki abban írhatná meg a logikát, amiben akarná, akinek meg mindegy, annak ott az alapértelmezésben is elérhető JavaScript motor a Rhino. Ez utóbbival (a még teljesen átgondolatlan API) valahogy így föst:

new DDLWriter();.generateDDL(new JPAReader(“target/test-classes”).readDefinition()).printAll();

Az elképzelés az, hogy csinálok egy Maven plugint, amibe ezt bele lehet írni konfigurációként. Persze ez rögtön általános Maven plugin lenne, amibe bármit lehetne írni bármilyen JSR-233az script nyelv segítsévégel. Akár már létezhetne is ilyen plugin (rákerestem, nem találtam), amivel ha mást nem a Maven kicsit merev logikáján és deklaratív eszméjén sikerülne rést ütni. Valahogy úgy mint az antrun plugin, csak itt ráadásul scripteket lehetne írni ANT XML részletek helyett.

És itt, hogy ne nyúljak túl hosszúra, inkább Szczepan Faber-t a Mockito szerzőjét idéznem:

“After Jason Van Zyl’s session I had an impression that he believes the best fit for the build system is a declarative architecture. I tend to disagree and I believe the build has inherent scripting nature.”

Tags: JPA, jsr223, maven, rhino, scripting

Jason van Zyl: Efficient Enterprise Builds

Thursday, December 11th, 2008 | Devoxx | 2 Comments

Gyakorlatilag Maven-es előadás, Maven és közel álló eszközökről: m2eclipse, tycho, maven, hudson, nexus.
A (számomra) érdekes rész a következő Maven kiadásról szóló fóliák voltak (Eclipset aktuálisan nem használok, Hudsont meg úgyis, Nexus telepítése todo listán) Rengeteg kisebb változás (versionless parent element, XML POM fromat with attributes), és rengeteg alapvető dolog: teljesen újraírt komponensek, teljesen kicserélhető részek, okosabb pluginelhetőség, mixinek stb.

Elég ígéretesnek tűnt, bár csak egy részét sikerült az újdonságokat felfogni. (A demó sajnos nem a részek közt volt, mert az laptop nem bírta a váltogatásokat). Néhány bejegyzéssel azelőtt pont azt némi ügyes kiterjeszthető hookot, és jól átgondoltásgot hiányoltam a Maven-ből,  úgy tűnik meg fogom kapni.

Tags: build, maven

Dependency management és Apache (pletykák)

Tuesday, December 9th, 2008 | Devoxx | No Comments

Na, akkor még egy kis pletyka. Miután az előző bejegyzést elküldtem, még beszélgettünk kicsit. Egyrészt valaki megkérdezte, hogy a Maven miért nem használja dependency managerként az IvY-t. Azt mondta Xavier, hogy volt róla szó, és beszélgettek róla a Mavenesekkel, és mindketten rendkívül nyitottak, csak még nem lett belőle semmi. Állítólag a Mavenbe nagyon bele van drótozva a függőség kezelés mindenhová, de vannak rá törekvések, hogy ez refaktorálva legyen, vagy esetleg cserélhető függőség kezelő legyen.

Beszéltünk még az EasyAnt-ról, ami az ő proof-of-concept projektje volt: ez egy ANT alapú de a Maven koncepcióit elsajátító rendszer volt. Én azt hittem, hogy elsikkadt az egész, de kiderült, hogy ugyan neki nincs rá ideje, de mások fejlesztgetik tovább (easyant.org), csak sajnos most csak egy patch-elt ANT-tal tud együttműködni. Elvileg a patchek átmennek majd az ANT forrásba, és az ANT következő release-vel lehet majd könnyen használni.

Valamint tt van még a Gradle (tegnap volt előadás, de nem azon voltam), ami egy Groovy alapú build rendszer, amit szintén IvY-t használ. Persze annak az IDE támogatása valószínű még rosszabb, ezért is izgalmas projekt az EasyAnt, mert ANT-ot viszont mindenki támogat, és ha ANTba okosan beépül, akkor már szinte mindenhol ott van.

Tags: apache, build, ivy, maven

Maven nyűgök

Monday, September 15th, 2008 | Uncategorized | 2 Comments

Lassan kikerülhetetlenül beszivárog az életembe a Maven minden előnyével és hátrányával együtt.

Az egyik legkényelmetlenebb dolog a használata közben, hogy ha egy projekt több modulból is áll, és az almodulok függenek egymástól, akkor a függőségeket nem fordítja újra a Maven egy adott almodul fordításakor.

A NetBeans pl. az ANT alapú projekteknél ezt csinálja: ha van egy közös lib projektem, amit a war és az ejb modul is használ, akkor a war fordításakor megnézi, hogy a lib-be változott-e valami, és ha igen automatikusan újra fordítja.

A Maven ilyet nem csinál (vagy nem tudom, hogy hogy lehet ezt elérni). Próbáltam rákeresni, de csak azt a választ találtam, hogy ilyet filozófiailag ne akarjak. A modulok önállóak, és ha változtatok valamit az egyikben, azt külön teszteljem, majd terjesszem az új változatot a repositoryn keresztül. Ezt a választ egy ideig el is fogadtam, csak a kolegáim kérdőjelezték meg, hogy talán egy csupa DTO-t tartalmazó projektet nem nagyon kell tesztelni, és az igazán le fordulhatna automatikusan, ha csak egy új gettert raktam bele.

(Ja, és még azt is ki kell derítenem, hogy hogyan lehet elérni, hogy hogy a package phase-ben ne hívódjon meg a jar:jar. Az ellenkezőjére már sok példát láttam, az executions jól megoldja, de az nem világos, hogy hogyen lehet törölni executionst. Lehet, hogy nem úszom meg, hogy a maven forráskódját is meg ne ismerjem?)

Tags: build, maven