[Javalist] maven függőség verziók rögzítése

[Gábor Garami]

"egyesek szerint". Egyesek szerint meg Isten idonkent sug neki, hogy
melyik verziot hasznalja. Konkretumok, konkret tesztek/peldak/esetek
nelkul legfeljebb vajakolhatunk. Adj valami linket erre az "egyesek
szerint" -re, vagy adj bovebb infot.

Amennyire en tudom, a maven fuggosegkezeleset ebbol az aspektusbol ugy
lehet befolyasolni, ha scope-ot adsz meg a dependencynek
(compile/runtime/test) de ez ugyebar a szandekos utja a
fuggoseg-modositasnak.

Amit irsz, az eddig eroteljesen bug-szagu, es nagyon utana kellene
nezni a dolgoknak, ezert is kellene valami bovebb info, mert kontextus
nelkul nem sok valaszra szamithatsz.


Garami Gábor
E-mail: gabor.garami at hron.me
Tel: +36 20 235 9621
MSN: hrgy at vipmail.hu
Skype: hron84


2013/11/12 Tamás Viktor <viktor.tamas at gmail.com>:
> Köszi a válaszokat!
> Az intervallum megadása nem igazán jó nekünk. Ez egy webapp, egy termék,
> amibe bele vannak csomagolva külső függőség jar-ok. Nem intervallumot akarok
> megadni külső függőségre, hanem konkrét verziót. Nem akarom hogy a Maven
> döntse el, hogy melyik verziót használja az intervallumból.
>
> Ez alapján világos, hogy legésszerűbb megadni a tranzitív dependenciákat is
> explicit. (Keresem hozzá az írott szakirodalmat, de ha van kéznél linketek
> azt szívesen venném.)
>
> A teszt vs runtime dologról van valami tapasztalatototk? (Tesztelésnél más
> verziókat használhat a Maven egyesek szerint.)
> Enforcer plugin-t használtok vagy akkor az már nem is kell, ha mvn
> dependency:analyze -t használok?
> Viktor
>
>
> 2013/11/8 István Viczián <viczian.istvan at gmail.com>
>>
>> Szia,
>>
>> Nem tudom, hogy jól értem-e, de leírom, amit értek. :)
>> A Maven mindenképpen azt mondja, hogy amit használsz a projektben, az
>> EXPLICIT, első szinten sorold fel! Ha hivatkozol B-re, az hivatkozik
>> C-re, de használod a C-t, és kiadod a
>>
>> mvn dependency:analyze
>>
>> Akkor mondja: "Used undeclared dependencies found:" a C-re.
>>
>> Minden könyv azt mondja, hogy ezeket meg kell szüntetni, azaz explicit
>> add meg a C-t. Feltételezem ezért van a "nearest definition"
>> algoritmus is.
>>
>>
>> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
>>
>> Aztán ott van a "Unused declared dependencies found:" rész is, sajnos
>> itt a reflection-nel felhúzott cuccokat nem találja meg, tipikusan a
>> Hibernate-et pl., ha JPA API-n keresztül használod.
>>
>> Szóval én ezt szoktam lefuttatni bizonyos időközönként, és megfixelni,
>> amit ír, hogy ne legyen baj.
>>
>> És igen, ahogy Péter is mondta, az exclude is a barátod. :)
>>
>> Üdv,
>>
>> --
>> Viczián István
>>
>>
>> Tamás Viktor <viktor.tamas at gmail.com> írta (2013. november 8. 9:41):
>> > Sziasztok,
>> > talán találkoztatok már olyan jelenséggel Maven projekteknél, hogy egy
>> > függőség verziójának emelésénél a tranzitív függőségek is változnak és
>> > esetleg konfliktus lép fel. Ez fordítási vagy futási idejű hibákat is
>> > eredményezhet.
>> >
>> > Tudtok bevett technikákat ennek a kezelésére? Pontosan akarom rögzíteni,
>> > hogy a projekt milyen verziójú függőségeket használ.
>> > Van az enforcer plugin, ami eltöri a buildet ha verziókonfliktust
>> > észlel.
>> > Meg lehet adni a függőségek verzióját így: <version>[1.2.3]</version>,
>> > innentől kezdve a Maven mindenképpen az 1.2.3-as verziót probálja
>> > használni.
>> > Eltöri a build-et ha nem sikerül ezt használni.
>> > Meg lehet adni explicit a tranzitív függőségeket, lehet nyisszantgatni
>> > exclude-dal a tranzitív függőségeket, szóval van mozgástér, csak azt nem
>> > tudom melyik a jó irány.
>> > Van valami bevett gyakorlatotok erre?
>> >
>> > Hallottam olyanról is, hogy bizonyos esetekben a unit tesztek nem
>> > ugyanolyan
>> > verziójú függőségekkel futnak, mint amik végül bekerülnek a build-be. Ez
>> > nem
>> > túl egészséges. Ezt el tudom képzelni, mert test-scope-pal behozhatunk
>> > olyan
>> > függőségeket, ami elmozdítja a tranzitív függőségek verzióit. De
>> > megerősíteni nem tudom. Találkoztatok már ilyennel?
>> >
>> > Üdv,
>> > V
>> >
>> > _______________________________________________
>> > Javalist mailing list
>> > Javalist at lists.javaforum.hu
>> > http://lists.javaforum.hu/mailman/listinfo/javalist
>> >
>> _______________________________________________
>> Javalist mailing list
>> Javalist at lists.javaforum.hu
>> http://lists.javaforum.hu/mailman/listinfo/javalist
>
>
>
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu
> http://lists.javaforum.hu/mailman/listinfo/javalist
>