maven dependency hell

Так сложилось, что в компании долгое время использовался инструмент http://ant.apache.org/. Круто, здорово, можно делать невероятные вещи и почти что запустить ракету на Луну с помощью него. Но за это приходится платить большим размером ant-скриптов, дублированием действий и прочими штуками, которые во множестве мест и статей уже описаны. Ещё один негатив - это т. н. jar-hell, когда у девелопера на локальной машине одна версия библиотеки (быть может, даже кастомная), у тестировщика другая, а у внедренца на продакшн-стенде - третья.

Перешли на http://maven.apache.org/. Круто, здорово, можно быстро и легко делать стандартные вещи. Если проект нестандартен и не подходит под maven-lifecycle - 99 %, что его целесообразнее стандартизировать - и будет круто и здорово.

Упрощение управлением зависимостями - одно из достоинств maven, которое часто упоминается.

Только вот беда с зависимостями всё равно есть - на этот раз maven-dependency-hell!

Примеры регулярно вижу в нашем прикладном коде.

Компонент А имеет версии 1 и 2. Компонент Б использует А:1. Компонент В использует А:2. Что будет в итоговом проекте, в котором одновременно запускаются Б и В? Плохо будет, однозначно.

ОК, предположим, коллеги (ну, и я в том числе, конечно) неправильно что-то делаем.

Но есть и другие примеры.

Ребята, пишущие junit-тесты, регулярно матерятся. Пишут тесты в junit v.4 стиле без следования устаревшим требованиям об именовании (имею в виду, название класса без Test или название метода не с test в начале, но с аннотацией @Test). В IDE - работает шикарно. Стартуем сборку mvn - тесты не видны. Почему? В ход идёт ключ -Х при запуске:

mvn -X clean package

Внезапно обнаруживается что-то вроде следующего:

org.apache.maven.plugins:maven-resources-plugin:jar:2.5 

  -> org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1

    -> junit:junit:jar:3.8.1

Т. е. v.3.8.1 подтягивается и успевает загрузиться первым. Ну, а ожидаемый и желанный junit:junit:jar:4.10 подтягивается позже, когда уже остаётся не при делах.

 

Да, в документации и про алгоритм определения провайдера почитали, и про задание версии surefire-junit4, и даже в своём pom-файле это прописали (правда, всё равно пока не особо помогает).

 

Может, я просто случайно так часто сталкиваюсь с этой проблемой с зависимостями.

Может, я/мы пока не достигли высокого уровня кулинарного мастерства для простого и вкусного приготовления с maven. Хотя описания подобного негативного опыта встречаются в сети.

Может, ещё что-то.

Но в любом случае - проблемы ant и maven практически одинаковы. А утверждающие, что в maven нет проблемы с зависимостями - либо не работали с более-менее крупными проектами и большим числом зависимостей, либо обладают какими-то магическими знаниями. Поделитесь источником тогда :)

P. S. Кроме -Х полезно также mvn dependency:tree (ну, и ещё -Dverbose=true) для отображения того же дерева зависимостей, но его иногда не хватает.