Развёрнутое пояснение:
1. При построении дерева зависимостей Maven обнаруживает core:1.4 через client: от приложения до этой зависимости два перехода.
2. Через adapter и bridge обнаруживается core:2.0: до неё три перехода.
3. Поскольку groupId и artifactId совпадают, Maven рассматривает эти зависимости как две версии одного артефакта и разрешает конфликт по правилу ближайшей зависимости.
4. Путь до core:1.4 короче, поэтому в путь классов попадает только версия 1.4. Более высокий номер версии не даёт приоритета, а сам конфликт версий обычно не прерывает сборку.
Почему это важно
Задача проверяет разрешение транзитивных зависимостей Maven. При добавлении библиотеки приложение может получить более старую версию общего артефакта, чем ожидает другой компонент. Если ему нужны методы из версии 2.0, во время выполнения возможен NoSuchMethodError. Дерево зависимостей помогает обнаружить такой выбор, а управление версиями — задать согласованную версию явно.
Post #8670
256
Чашечка Java Maven разрешает зависимости: app → client → core:1.4 и app → adapter → bridge → core:2.0. Обе версии core имеют одинаковые groupId и artifactId; все зависимости — compile, управления версиями нет. Какая версия core попадёт в путь классов приложения?