iBATIS 3 - nový bojovník přichází

Jsem dlouholetý uživatel Hibernate, které používáme na velkém projektu a musím se přiznat, že dnes nám spíš přináší komplikace (především u 50GB databáze už hodně záleží jaká SQL se volají a to nám Hibernate neumožňuje ovlivnit). iBATIS to umí i ve verzi 2. Co se mi líbilo na návrhu připravované verze 3 jsem již psal. Ale my tu již máme první betu trojky. (Než se pustím do svých postřehů, rád bych zmínil seriál otce Fura, který je vyčerpávajícím popisem novinek v porovnání s dřívější verzí iBATISu.)

Krom věcí zmíněných již v předcházejícím článku existují další, které mě hodně potěšili:

• vytváření TypeHandlerů je o poznání jednodušší než podobných UserTypů v Hibernate
• objekty natažené z DB nejsou vytvářené pomocí bezparametrického konstruktoru, ale pomocí ObjectFactory, takže máte způsob vytvoření objektu plně v ruce (objekty půjde vytvářet pomocí DI frameworku - Spring, Guice) - to je obrovská bolest Hibernate, která se řešila pomocí AOP
• vytváření dynamických SQL

Jsem moc rád že komunita za iBATISem stojící sebrala odvahu a vrhla se do designu nového frameworku, i když je to za cenu menší zpětné kompatibility. Moc se jim nový iBATIS povedl a řada věcí řeší bolesti, na které musí každý kdo používá Hibernate narazit.

Spolu s iBATISem byl uvolněn i další produkt a to iBATIS Schema Migration System, který umožnuje automatizovat migraci DB schéma z jedné verze tam i zpět (pokud si SQL skript na zpětnou migraci napíšete). Inspirace jistě pochází z Ruby on Rails Migrations. Bohužel Migrations jak je představil team iBATISu mají jeden zásadní problém: migrační scripty se píší přímo v SQL. Takže jen velmi těžko budeme vytvářet skript, který bude fungovat s různými databázemi nebo s různými konfiguracemi téže databáze.

Gradle - první krůčky

O novém build nástroji gradle jsem již psal. Je to už rok a co se za tu dobu stalo? Gradle nám vyrostl z verze 0.2 na verzi 0.7, která je už velmi rozumně použitelná. A proto jsme se rozhodli gradle použít pro náš první projekt.

Jedná se o velmi jednoduchý projekt (matcher pro easymock). Tento projekt obsahuje 3 třídy, které je potřeba zkompilovat. Neobsahuje testy. Výsledný jar je nutno deploynout do firemní artifactory.

A jak takovéto jednuché věci dosáhnout:

usePlugin "java"
usePlugin "maven"

sourceCompatibility = 1.6
group = "cz.svt"
version = "${version}"

manifest.mainAttributes "Implementation-Title": name, "Implementation-Version": version, "Implementation-Vendor": "ČSAD SVT Praha s.r.o." 

configurations {
   deployerJars
}

dependencies {
   compile "commons-beanutils:commons-beanutils:1.7.0" 
   compile "org.easymock:easymock:2.2"
   compile "org.easymock:easymockclassextension:2.2.1"
   
   deployerJars "org.apache.maven.wagon:wagon-http:1.0-beta-2"
}

repositories {
   mavenRepo urls: "${artifactoryURL}/repo1"
}

uploadArchives {
   repositories.mavenDeployer {
      name = 'httpDeployer'
      configuration = configurations.deployerJars
      repository(url: "${artifactoryURL}/libs-releases-local") {
         authentication userName: "${artifactoryUid}", password: "${artifactoryPwd}"
      }
      snapshotRepository(url: "${artifactoryURL}/libs-snapshots-local") {
         authentication userName: "${artifactoryUid}", password: "${artifactoryPwd}"
      }
   }
}

Maven uživatel může jenom závidět, jak je tento script kompaktní a krátký. Nyní si postupně projdeme co musíme ve scriptu udělat, aby vše fungovalo.

Nejprve definujeme, které pluginy budeme používat. java plugin potřebujeme pro překlad Javy a maven pro deployment do artifactory (jedná se o maven repository).

Další 3 řádky definují, že používáme Javu 1.6, skupina deployovaného artefaktu je "cz.svt" a na verzi se odvoláváme jako na property (o těch si povíme dále). Následuje řádek s definicí manifestu (hojně používáme property dříve nastavené).

Další 3 řádky definují novou konfiguraci deployerJars, kterou použijeme v tasku na deployment jaru do naší sdílené firemní artifactory.

A začínáme tím zajímavým, závislostmi. Stačí nám na ně 7 řádků. Závislosti se definují podobně jako v mavenu, ale skupiona, název, verze se oddělují dvojtečkou. Jinak gradle umí díky ivy pracovat nejen s ivy, ale i maven repository. Poslední závislost říká, že deployování bude potřebovat wagon-http.

Následně defunujeme repository pro resolvování závislostí (opět pomocí property). Poslední je task uploadArchives, který je nejsložitější z celého scriptu. Složitost ovšem spočívá v definování rozdílné repository pro snapshoty a pro finální verze (v podstatě dvakrát to samé). Protože deployment do artifactory nemůže provést každý, je nutné specifikovat už. jméno a heslo (není přímo ve scriptu, ale je to properta).

Jak gradle resolvuje property? Gradle hledá v aktuálním adresáři soubor gradle.properties a dále se kouká do adresáře $HOME/.gradle/ po stejnojmenném souboru. V těchto souborech můžeme definovat property, jenž můžeme využít v buildu. Takže v projektu uvádíme verzi a v domovském adresáři definujeme adresu repository a už. jméno a heslo.

A jaké budou další krůčky? Nejprve přidáme testy, pak generování standardních reportů (javadocs, findbugs, cobertura) a nakonec groovy, aspectj atd...