Как изолировать библиотеки в неуправляемом файле зависимостей .jar, чтобы они не конфликтовали с другими

Мне нужно добавить .jar в качестве неуправляемой зависимости к проекту sbt Scala (это java-stellar-sdk). Все работает хорошо, пока я не запускаю sbt test. Кажется, в файле .jar есть версия Mockito, которая конфликтует с той, которую я использую в проекте. Я получаю много ошибок, что некоторые сопоставители Mockito не найдены, но все работает нормально без .jar в папке lib.

Есть ли способ сообщить sbt, что он должен игнорировать определенные библиотеки в .jar или что управляемые зависимости имеют приоритет? Я также нашел этот связанный вопрос, но, очевидно, это мне не помогло.

Альтернативный обходной путь также очень поможет. Можно ли изолировать библиотеки в банке таким образом, чтобы я мог просто сделать определенный пакет видимым снаружи?

Обновление: .jar содержит Mockito 2, но в моем проекте используется Mockito 1, так что это очень простой и очевидный конфликт, который я могу решить путем обновления до Mockito 2 (который я пробовал, и он работает). Однако остается вопрос: есть ли другой разумный способ изолировать зависимость Mockito в .jar, чтобы не мешать моему проекту, если я не могу или не хочу разрешить конфликт, купив переход на более новую версию библиотеки обсуждаемый. Может быть, изменить .jar, чтобы переименовать конфликтующие пакеты? Я не знаю. Что-то такое.

Я знаю, что это очень общий вопрос, который, вероятно, подробно обсуждался где-то еще. Тем не менее, я не нашел ничего, что меня действительно удовлетворило бы. Ссылки на соответствующие обсуждения темы, конечно, также приветствуются.


scala sbt dependency-management conflicting-libraries
person lex82    schedule 07.03.2018    source источник
comment
Если вы предлагаете вознаграждение за это, вы, вероятно, должны хотя бы предоставить соответствующие фрагменты файла build.sbt. В противном случае это больше похоже на довольно расплывчатое утверждение о том, что где-то есть какой-то баночный ад.   -  person Andrey Tyukin    schedule 10.03.2018
comment
@AndreyTyukin, я обновил вопрос и попытался прояснить, о чем я прошу.   -  person lex82    schedule 11.03.2018
comment
Вы можете опубликовать содержимое build.sbt?   -  person Akash Tantri    schedule 12.03.2018
comment
@AkashTantri, я расширил вопрос, чтобы объяснить, почему build.sbt не имеет значения. Я не спрашиваю, как решить мою конкретную проблему (что я уже сделал), но это общий вопрос.   -  person lex82    schedule 12.03.2018

Ответы (2)


arrow_upward
3
arrow_downward

Я могу придумать 3 способа сделать это (в порядке от простого к сложному):

  1. удалите mockito 2 вручную из файла jar.
    Поскольку jar — это просто zip-файл, вы можете извлечь его, удалить все конфликтующие файлы и снова запаковать.

  2. скомпилируйте эту банку из исходного кода самостоятельно и установите mockito в качестве тестовой зависимости (как и должно быть). Если вы это сделаете, рассмотрите возможность открытия PR с вашим изменением, чтобы решить проблему для сообщества.

  3. Затенение mockito-файлов в jar-файле.
    затенение — это процесс переименования всех файлов в jar-файле по определенным правилам. вы можете использовать jarjarlinks или плагин сборки sbt. см. этот ответ, чтобы начать работу со сборкой sbt: https://stackoverflow.com/a/47974750/245024
person lev    schedule 11.03.2018

arrow_upward
1
arrow_downward

Вы должны иметь возможность настроить так, чтобы ваши классы Mockito 1 отображались перед классами Mockito 2 в пути к классам. Это заставит ваши классы побеждать в любых конфликтах.

person Rich    schedule 13.03.2018
comment
Хорошо, как мне это сделать? Классы Mockito 2 находятся в файле .jar в папке lib. Зависимость Mockito 1 находится в файле sbt. - person lex82; 13.03.2018