[Java lista] Maven local repo beallitas

Tamás Cservenák tamas at cservenak.net
2009. Okt. 30., P, 10:43:16 CET


Ez mind szep es jo, de....

Az "indirekcios szint" (ami a MRM) szukseges mert:

* sokan vaskalaposan mai napig azt hiszik, hogy egy remote repo (es ez igaz
a Maven, de az OSGI [P2/OBR/...] vilagra is! Tovabbmegyek, es a Ruby/GEM,
RPM-MD, stb) uzemeltetesehez eleg egy kis file rendszer es HTTPD felette.
Kesz.
* a fentiek miatt a "paradigma valtas" nehez, egyseges allaspont sohasem
lesz
* sokak szemeben a remote repo az valami "statikus" (FS + HTTPD) es nem
dinamikus (alkalmazas, mint a MRM). Nagyon nehezen tudtuk elerni, hogy az
Apache Snapshots repo "dinamukus" MRM legyen (https://repository.apache.org/),
sok ellenallas volt ilyen kerdesekkel, hogy "minek ez?". Ma, par honap
mukodes utan igenis belatjak hogy mennyire jo es egyszerusiti az ember
eletet a staging. (regebben iszonyu komplikalt es nehezkes volt: WebDAV a te
apache home-odba, szavazas, majd rsync a repoba, stb. Sok hibalehetoseg,
nincs visszalepes, kezzel kellett "javitgatni" a fajlokat). Nezd mennyi
Apache projekt "tert meg"! Termeszetesen, meg mindig van ellenallas.
* sokszor NEKED kell "kijavitani" (szamodra elfogadhatova tenni) valamit,
amit a repo tulaj nek akar, nem hajlando, nincs stb.
* stb.

Es ne mondjam, hogy nem lehet az osszes problemat a "tavoli vegre" (a repo
uzemeltetojere) terhelni mindig. Ezek altalaban OSS repository-k, es ott
vagy nincs penz vagy nincs keret.

2009/10/29 Verhás István <istvan at verhas.com>

>  A hivatkozott cikk azt is említi, hogy ha open source lib-t készítesz
> akkor az a legjobb ha a central repository-ba bekerül. Én úgy látom, hogy az
> egy központi repo erőltetése nagyon hasonlít arra mint amikor még mindenki
> magának írta a hosts fájlt. Aztán egész jó megoldást sikerült kitalálni erre
> a probléma körre. Szerintem jobb minőségű lenne a central repo ha a DNS
> szervekhez hasonlóan hierarchiába lennének szervezve és elosztottan működne.
> Ez alatt nem csak a technikai szintű elosztást értem, hanem az
> adminisztratív részét is kezdve a groupID kiosztással és kiosztási jog
> delegálással. A name szerverben sem kell felvenni újabb és újabb "IP cím
> respository"-kat, hanem egyszer megtanulta azt a néhány root szervert és ha
> nincs tippje akkor onnan kérdez.
>
> ĂĽdv
> vi
>
>
> Tamás Cservenák wrote:
>
> 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
>>
>>   ------------------------------
>
> _______________________________________________
> Javalist mailing listJavalist at javagrund.huhttp://javagrund.hu/mailman/listinfo/javalist
>
>
> _______________________________________________
> Javalist mailing list
> Javalist at javagrund.hu
> http://javagrund.hu/mailman/listinfo/javalist
>
>
--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: http://javagrund.hu/pipermail/javalist/attachments/20091030/b30c0232/attachment.html 


További információk a(z) Javalist levelezőlistáról