[Java lista] Maven local repo beallitas

[Zsombor]

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

> 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<http://repository.sonatype.org/index.html#nexus-search;classname%7Eorg.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~
>>
>

Hmm. akkor talán előbb utóbb lehet majd azt mondani a maven-nek, hogy az én
repositorym, az egy subversionben tĂĄrolt lib kĂśnyvtĂĄr legyen, a projektem
alĂĄ becsekkelve? :) SzĂĄmos problĂŠmĂĄt megoldana ! :)

Zs
--------- következő rész ---------
Egy csatolt HTML ĂĄllomĂĄny ĂĄt lett konvertĂĄlva...
URL: http://javagrund.hu/pipermail/javalist/attachments/20091029/6563b210/attachment-0001.html