[Java lista] Maven local repo beallitas
Tamás Cservenák
tamas at cservenak.net
2009. Okt. 29., Cs, 14:44:40 CET
Hat, sokmindent.
1. Maven 2.2.1 - sok a bugfix, a fent emlitett 2.0.9-tol pontosan 196 darab
(ha jo a JIRA filterem, de bujkalnak itt JIRA szakik is!)
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&&pid=10500&status=5&status=6&fixfor=15328&fixfor=15103&fixfor=14587&fixfor=14503&fixfor=14112&sorter/field=issuekey&sorter/order=DESC
2. Eclipse + M2Eclipse - ez valojaban csak "kenyelem". A CLI build meg
mindig a "kanonizalt" (az igazi, tehat pontositok: console + Eclipse), de
nagyon jol jon egy alapbol beallitott IDE (amit az M2e elvegez a POMot
olvasva es ertelmezve). Tovabba, a dependency tree, annak filterezese,
context help a POM szerkesztesenel, incremental build (igen! uj maven3
feature), stb... csak sorolhatom. Az index bongeszese/integralasa mar csak
"hab a tortan"... De valojaban ezekkel, egy "pure Maven project" _majdnem_
1st class citizen lesz az Eclipse-ben.
3. Ez nagyon hosszu, csinaljatok egy teat/kavet elotte.
Jelenleg is vita targya, es en a cegben e temaban az oppoziciot
kepviselem... a "hivatalos" allaspont itt van:
http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/
Es ez szerintem nem teljesen igaz. Egy Maven project az "svn co http://..."
utan _buildelheto_ kell hogy legyen, a fentieket hasznalva NEM LESZ AZ. Az
"argumentum" a fenti blogban az, hogy az URLek valtoznak, ennelfogva a ket
eve releaselt/deployolt POMok (a Maven remote repo as csak "elore mozoghat",
ami benne van az kobe van vesve, nem valtoztathato. Pl. akar as SVN repo)
egy pillanatban (pl. mikor a repository.verhas.com egy ceges bevasarlas
miatt atkerul a repository.verhas-atlassian.com-ra) egyszeruen nem lesz
fordithato tobbet.
Ez mind igaz, de: ha nem hagyunk semmi "nyomot", hogy milyen repot
hasznalunk (vagy ohajtunk hasznalni), akkor semmit informaciot nem adunk az
"utokornak". A fenti peldaval elve, a regi POM "javithato" lesz miutan a
manus guglizik egyet, es rajon hogy a V&V zsebbetette az atlassiant, majd
utananez hol az uj repo es mehet is a build.
Tehat, szerintem _kell_ URL, mert az _informacio_ erteku.
Es hogy visszakanyarodjak az eredeti temahoz, mit hoz az MRM az asztalhoz:
Ha "huzunk egy hasonlatot", es azt mondjuk, hogy a POM :== Project Object
Model, es hogy a Maven environment szerves resze a settings.xml-is, megis ra
kell jonnunk, hogy valami hianyzik.
Ez pedig a BOM :== Build Object Model. Ez valojaban a kornyezet. Kell egy
"indirection layer" pont emiatt, hogy lehetoseg legyen "utolag" cserelgetni
(termeszetesen ez lehet shoot in the foot is, ha nem vigyazol!) a hasznalt
repokat. Es itt is vagyunk: A jelenlegi paradigma a Maven "best
practice"-hez a kovetkezo:
* a POM-ban ne legyen semmi repo (sztem ez rossz!)
* settings.xml tartalmazza a mirrorOf* sort, ezzel a maven "felulir" minden
POM-beli repo definiciot es a MRM-re kuldi a remote repo requesteket, ahol
* egy MRM repository group definialasa, ami _minden_szukseges_repository_-t
tartalmaz.
Es itt az aggalyom: ezzel "kitoltuk" a build environmentet a Maven CLI-rol
(POM es a settings.xml semmit sem tartalmaz a szukseges repokrol, vagy csak
hianyos es vagy pontatlan informaciokat) a MRM-re. Es ugye te nem fogsz
emlekezni, hogy a "public" group mely 23 repository-t tartalmazta 2 evvel
ezelott?
Tehat, ami hianyzik, az valami BOM, ami ezt tartalmazza, es a sima "svn co
... mvn clean install" igy modosulna:
1) svn co ... (ezzel megvan a POM-od is)
2) a projekt src-je (vagy csatoltan) tartalmazna BOM-ot is, ezt letoltod, es
mondjuk ra "megeteted" a MRM-eddel (igen, szabvanyositani kellene de biztos
lesz aki "nyomatja" :D )
2a) a MRM elkezd rikacsolni, hogy repoA, repoB nem letezik, de kis
"tuningolassal" vegul beall a rend (all reposes in group reachable and OK)
3) mvn clean install
Egy fontos tenyezo! A Maven2 egy outstanding bug-gal rendelkezik, melyet
csak a Maven3 fog javitani, meghozza: ha egy transitive dependency POMja
tartalmaz repository definiciot, azt a Maven2 "beteszi" a te projektedben
hasznaltak koze, es elkezdi hasznalni! Ezt hivatott megoldani a mirrorOf*,
mert az "elcsip" minden kimeno request-et.
Thanks,
~t~
2009/10/29 Zsombor <gzsombor at gmail.com>
>
> Eme három dolog mit ad hozzá a 'maven' élményhez?
>
> Zs
>
>
--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: http://javagrund.hu/pipermail/javalist/attachments/20091029/3bc41c1d/attachment-0001.html
További információk a(z) Javalist levelezőlistáról