[Java lista] Maven local repo beallitas

Tamás Cservenák tamas at cservenak.net
2009. Okt. 29., Cs, 14:57:32 CET


Jaj de elhuztam, es elfelejtettem a mindennapi "jot" a MRM-bol. Tehat:

3) Ma: http://maven.apache.org/repository-management.html
Tovabba repo grouping, procurement, staging, P2 hosting/proxying, OBR
hosting/proxying stb.
Holnap: elozo level 3), tehat csak fontosabb lesz

Igaz, a fenti, foleg corporate environmentet celzo feature-ek mellett, nekem
is mint sima foldonfuto (es villamosozo a lakasom es iroda kozott) is
hasznos: azonnal tudok keresni a central-ban meg a tobbi repoban (aki
publikalja az indexet) akar Class name-re is akar offline:
http://repository.sonatype.org/index.html#nexus-search;classname~org.sonatype.nexus.DefaultNexus

Akar identifikalhatok egy "ismeretlen" JAR-t (checksum search), stb. Es, ami
a legfontosabb, kulonbozo projektjeimhez ("ceges", "szegedi", "private-oss",
stb) kulon kulon repo group-okat definialok, es "tisztan tartom" a
kornyezetemet.... stb. De ez mar egy kicsit a BOM sztori.


Udv,
~t~


2009/10/29 Tamás Cservenák <tamas at cservenak.net>

> 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/bd35dea4/attachment.html 


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