Otázka:
Představte si, že máte větší strom závislostí, kde se projekty odkazují na další projekty a ty na další...Pokud se v takovém stromě stane, že máme závislost (dependency) na stejný artefact (stejné groupId i artefactId) a liší se pouze verze artefaktu.
Která závislost se použije?
Odpověd:
Jaká verze knihovny
se použije se určí podle těchto pravidel:
- Když jsou knihovny na stejné úrovni, vyhodnotí se jako vítězná ta co je jako první v pom.xml
- Pokud jsou knihovny na různých úrovních v závislostech, vyhraje ta s nejnižším stupněm zanoření v grafu
- eg. if dependencies for A, B, and C are defined as A -> B -> C -> D 2.0 and A -> E -> D 1.0, then D 1.0 will be used when building A because the path from A to D through E is shorter. You could explicitly add a dependency to D 2.0 in A to force the use of D 2.0
Řečeno jinak použije se ta knihovna, která se při prohledávání grafu závislostí do šířky najde jako první.
Zcela nedůležitá poznámka:
Mě osobně to trochu překvapilo, protože jsem spíš očekával, že se použije ta knihovna, která se najde jako první při prohledávání do hloubky (a ne do šířky).
Pokud někdo víte proč to funguje takhle zvláštně do šířky a ne do hloubky, tak mi to prosím vysvětlete.
Začínám být z toho Mavenu pěkně otrávený, proč musím build projektu programovat v nějakých hloupých XML souborech. Jak to mám debugovat? Proč se musím učit syntaxy pom.xml a pak složitě zjišťovat co to vlastně udělá. Jak krásné by bylo napsat to v Jave a v případě problému si to pustit v Debugu. Chvilemi se mi chce psát si vlastní build nastroj. Ach jo... :)
Začínám být z toho Mavenu pěkně otrávený, proč musím build projektu programovat v nějakých hloupých XML souborech. Jak to mám debugovat? Proč se musím učit syntaxy pom.xml a pak složitě zjišťovat co to vlastně udělá. Jak krásné by bylo napsat to v Jave a v případě problému si to pustit v Debugu. Chvilemi se mi chce psát si vlastní build nastroj. Ach jo... :)
