Ahoj.
Tento mail sa bude tykat prevazne linuxakov a mal by byt akymsi "stuchancom"
do diskusie ohladne balikovania java aplikacii na linuxe. Ospravedlnte prosim
jeho roztahanost a chaotickost ( pisal som to narychlo kym to drzim v hlave ).
Bol by som rad, keby sa mi k tomuto mailu vyjadrili java linuxaci, co maju
viac skusenosti s javou a mavenom a zhruba tusia co-to o linuxe.
V linuxovom c++ svete su aplikacie distribuovane (prevazne) v balikoch. Pokial
aplikacia dependuje na nejakych knizniciach ( povedzme libfoo,
apache-commons-io a tak podobne ), tieto su takisto zabalene do samostatnych
balikov a v balickovacom systeme sa vytvori zavislost aplikacie na jej
knizniciach.
To znamena, ze pokial niekto chce nainstalovat FooApp, automaticky sa mu
nainstaluju libfoo a apache-commons-io.
Pocas baliaceho procesu v lepsich balickovacich systemoch ( napr. debian )
baliace scripty automaticky podla zavislosti v .so knizniciach dokazu urcit
zavislost aplikacie na knizniciach.
U java aplikacii v linuxe je situacia ale zasadne odlisna (podla mojho nazoru
katastrofalna). Aplikacie sa instaluju akymysi pochybnymi instalatormi, cim
je znemoznene instalovat inam ako do $HOME, neriesia sa zavislosti a tak
podobne.
Uz z principu .jar je jasne, ze z neho nie je rozumne mozne urcit zavislosti a
vsetko sa musi robit rucne. Package maintainer musi rucne zistit zavislosti (
googlom, skumanim kodu atd ), povyrabat rucne descriptory balikov, vyrobit
baliky, rucne nastavit zavislosti, rucne vyrobit spustaci script, otestovat
to ...
Hrozna praca.
V java svete dost casto narazam na situaciu, ze kazda aplikacia si so sebou
taha kompletny bundle kniznic. Mne to pride typicky windowsacke, pretoze ta
napodobenina OS skutocne nema ziaden rozumny dependency management.
Dochadza tym ale k obrovskemu plytvaniu a chaosu. V linuxe by sa to ale malo
riesit cestou zdielania zdrojov (kiniznic).
Odskok bokom:
U javistov som sa stretol s nazorom, ze je to tak dobre, pretoze nemoze dojst
k roznym chybam plynucim z moznej nekompatibility. Podla mojho nazoru ale
situacia nie je tak horuca, pretoze od toho tu predsa mame cislovanie verzii,
z ktorych sa da urcit, ci je api kniznice spetne a dopredne kompatibilne s
pozadovanym stavom. Pokial sa toto cislovanie dodrzi, problem odpada.
Navrat:
Casom ako sa zoznamujem s mavenom, silne mi to pripomina zavislosti v
linuxovych balikoch. A tak sa mi vnukla myslienka, ci nevyuzit jeho
dependency management na akesi "automaticke" vytvorenie linux balikov z
mavenizovaneho projektu.
Samotny maven nepomoze, pretoze riesi len vyvoj, nie dalsi zivot aplikacie. Na
samotne spustenie aplikacie je bud potrebne mat k dispozicii potrebne jar-y
niekde na disku, alebo assemblovat zavislosti spolu s aplikaciou ( co zase
naburava celu ideologiu a nafukuje aplikaciu o megabajty chaosu), programovat
spustacie scripty a tak podobne. Jeho /dependencies/dependency by sa dal
lahko vyuzit.
Priklad:
<groupId>net.test</groupId>
<artifactId>MyLibrary</artifactId>
<packaging>jar</packaging>
<version>2.0</version>
Z tychto informacii dokazem vytvorit meno linuxoveho
baliku "MyLibrary-2.0.deb", to je prvy krok.
Pokial by som vyriesil, aby mvn install neinstaloval do ~/.m2, ale napr.
do /usr/local/java/maven/, mohol by som po mvn install rovno vysledok zabalit
a balik by bol hotovy.
Vysledok:
usr
local
java
maven
repo
net
test
MyLibrary
2.0
MyLibrary-2.0.jar
MyLibrary-2.0.pom
Nasledne by bolo mozne z nasledovnej aplikacie vyrobit dalsi
balik "MyApplication-1.0.deb" s podobnou stromovou strukturou.
<groupId>net.test</groupId>
<artifactId>MyApplication</artifactId>
<packaging>jar</packaging>
<version>1.0</version>
<dependencies>
<dependency>
<groupId>net.test</groupId>
<artifactId>MyLibrary</artifactId>
<version>2.0</version>
Kedze pom.xml ma dependencies, slo by v zavislostiach -baliku- urcit, ze
zavisi na MyLibrary-2.0.deb. Takisto by sa mohlo z pom-u ziskat main-class a
vyrobit spustaci script:
#!/bin/bash
java -cp /usr/local/java/maven/repo/net/test/MyLibrary/2.0/MyLibrary-2.0.jar
/usr/local/java/maven/repo/net/test/MyApplication/1.0/MyApplication-1.0.jar
net.test.Main
Nasledne by po instalacii MyApplication doslo k automatickej instalacii
MyLibrary a vytvoreniu scriptu co aplikaciu spusti.
Vysledok:
usr
local
bin
myapplication (.sh)
java
maven
repo
net
test
MyLibrary
2.0
MyApplication-1.0.jar
MyApplication-1.0.pom
Teraz by este bolo dobre nejakym sposobom spristupnit repozitar v /usr pre
java vyvojara tak, aby mohol pouzivat kniznice z balikov.
Pokial ma maven moznost pouzivat 2 lokalne repozitare ( musim overit ), mohol
by pouzivat ~/.m2 klasicky ako doteraz a k tomu este projekty z /usr ako
projekty distribuovane spolu z linuxom.
A bolo by to vyriesene. Pokial by niekto programoval java aplikaciu na linuxe,
ktora by pouzivala napr. commons-logging, stacilo by mu spustit:
aptitude install apache-commons-logging, vyvinut danu aplikaciu,
zabalit ju (nejak automaticky, napr. maven pluginom ) do .deb baliku a
distribuovat. Pokial si ju bude chciet niekto iny nainstalovat, automaticky
sa mu nainstaluju commons-logging a moze ju zacat hned pouzivat.
Co si o tomto celom myslite?
--
Dusan
... tykajte mi
