Maven 2 - разные версии зависимостей в тесте и компиляции - PullRequest
12 голосов
/ 05 июля 2011

У меня есть проект, который зависит от commons-httpclient [2.0] (компиляция).

Я хотел бы написать несколько тестов jbehave - jbehave-core 3.4.5 (test).Обе эти зависимости зависят от commons-lang, но в разных версиях - 1.0.1 и 2.5.

dependency

Когда я выполняю пакет mvn , я получаю [BUID FAILURE] в разделе тестов.Исключение для моего тестового примера в выходных данных плагина surefire:

java.lang.NoSuchMethodError: org.apache.commons.lang.StringUtils.substringBeforeLast(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;

Как я посмотрел в исходном коде - в commons-lang 1.0.1 - действительно, нет StringUtils.substringBeforeLast (...)метод.Почему maven использует commons-lang из commons-httpclient (compile), а не из jbehave-core при тестировании?

Я не могу позволить себе исключить эту конфликтующую зависимость в commons-httpclient, поэтому она должна оставаться во время компиляции.

Так как это можно решить?- версия commons-lang 2.5 в тестировании и 1.0.1 во время компиляции.

Ответы [ 2 ]

6 голосов
/ 05 июля 2011

попытайтесь определить 2 разных тега <dependency> с разными версиями и областями применения.Используйте тег <scope>test</scope> внутри зависимости для тестов и <scope>compile</scope> для компиляции.

0 голосов
/ 08 июня 2018

Очень плохая идея иметь две разные версии для зависимости компиляции и тестирования:

Ваш не тестовый код может зависеть от поведения более нового JAR и не работать при использовании классов более старого JAR. Когда вы используете более старый JAR-файл в своих тестах, неиспользуемый код не будет работать со старым JAR-файлом.

В противном случае вы могли бы использовать более старый JAR где угодно, с той же версией ... Если вы добавите обе версии JAR в ваш путь к классам, вы не сможете узнать, какая из них будет выбрана при запуске ваших тестов. Это тоже плохая идея.

Следовательно, вы должны получить non-test и протестировать с той же зависимостью версии JAR.

...