Apache Maven

Za Maven sem prvič slišal pred slabim letom. Na njega sem naletel iz projekta Forrest, ki sem ga uporabljal za projektno dokumentacijsko intranetno spletno stran. Takrat je bil še v prvi inkarnaciji, to je v verziji 1.0. Nisem si vzel dovolj časa za evaluacijo, zato je bilo tedanje razumevanje tega ogrodja zelo površno. Pravzaprav sem ga nameraval uporabljati samo iz ene perspektive tj. kot pripomoček pri izdelavi projektne dokumentacije. Zdaj so za mano kaki trije meseci uporabe verzije 2.0, ki pa se kar v precejšnji meri razlikuje od prve.

Apache Maven je ogrodje za pomoč pri projektni organizaciji procesov (project management framework). Odprtokodni projekti so si med seboj zelo različni po zrelosti kode, konceptih in načinih izdaj verzij, nadgradenj in popravkov. Že na začetku moram omeniti, da so potrebni pri uporabi Maven ogrodja močni živci in zvrhana mera potrpežljivosti. Do izida knjige Better Builds with Maven je bilo prebijanje skozi razmetano dokumentacijo na uradni strani pravo doživetje in malo je manjkalo, da nisem vsega skupaj poslal k vragu. Vseeno sem imel občutek, da je za vsem skupaj nekaj dobrega. In po dosedaj videnem sem imel kar prav.

Maven je:

1. zbirka standardov
2. repozitorij programskih knjižnic
3. orodje za opis projektov
4. orodje za projektno organizacijo

Za najbolj pomembno vrednost sem spoznal dejstvo, da definira cikle za prevajanje kode, testiranje in nameščanje programskih artefaktov. Ker vedno več projektov uporablja Maven v procesu razvoja programske kode, je zaradi uporabljenih konvencij izredno zmanjšan uvodni čas pri spoznavanju projekta.

Z leti se izoblikujejo določeni vzorci in nekateri so prepoznani kot boljši. Če te vzamemo in združimo z deklarativnim pristopom opisa projekta, namesto da vsakič znova uporabljamo bolj ali manj spremenjene build skripte, potem lahko določene postopke poenostavimo.

Firma, če povzamem enega izmed avtorjev, lahko z uporabo Maven ogrodja pridobi na področjih:
Koherenca - To pomeni standardizacija na področju najboljših pristopov, ki so se izoblikovali.
Reuporaba - Ne izumljamo že videnega, ampak raje uporabimo kar se je izkazalo za dobro.
Agilnost - Razvojniki lažje prestopamo iz projekta na projekt, ker ni potrebnega uvodnega spoznavanja s sistemom.
Vzdrževanje - Razbremenitev ljudi, ki so prej pisali razne skripte, pogosto niti v okviru standardov firme (če sploh obstajajo).

Brez teh lastnosti že v skupini prihaja do velikih razlik med postopki razvoja. To ni nujno tako slabo, a nobena skupina ne vključuje posameznikov z istim znanjem, željami, voljo in še čim, da ne bi prihajalo vsaj do občasnih zastojev dela zaradi nedefiniranih postopkov. Ko v tako skupino pride nov član, je bolj ali manj odvisen od svoje iznajdljivosti, saj so postopki redko popisani.

Princip uporabe konvencij raje kot konfiguracij pomeni, da uporabljamo vnaprej dogovorjene vzorce in jih le po potrebi konfiguriramo. Eden izmed takih vzorcev je standardna direktorijska struktura. Kolikokrat ste se že znašli v situaciji, da ste premišljali kam bi šla kakšna datoteka? Verjetno večkrat kot je to potrebno, zraven pa še poželi negodovanje sodelavca, ki si je stvar zamislil malo drugače. Poznano? Naslednja stvar, ki je pomembna je višjenivojska organizacija kode v projektu ali drugače rečeno - princip ločevanja odgovornosti (Separation of Concerns). To pomeni več-modulski projekt. Še tretja stvar, ki jo bom omenil pa je standardno poimenovanje artefaktov, ki jih proizvajamo v procesu razvoja. To so na primer datoteke JAR.

Obsežna tema, zato verjetno sledi nadaljevanje.