Maven: версия Shade, используемая вместо сторонней зависимости

Скажем, мой проект называется A, а Foo и Bar — сторонние библиотеки. A зависит от Foo версии 1 и Bar. Бар зависит от Foo версии 2:

A -> Foo version 1  
  \-> Bar  
      \-> Foo version 2

С этой конфигурацией плагина Maven Shade в моем проекте, A, POM

<relocation>
  <pattern>Foo</pattern>
  <shadedPattern>FooA</shadedPattern>
</relocation>

версия, которую я использую, Foo версии 1, будет переименована/перемещена в FooA.

Вопрос: можно ли вместо этого переименовать/переместить Foo версии 2? Я знаю, что это можно сделать, если я смогу модифицировать POM Bar, однако я не могу этого сделать, так как я не являюсь дистрибьютором Bar.


maven maven-shade-plugin
person flow2k    schedule 08.10.2018    source источник
comment
Возможный дубликат несколько версий одной и той же зависимости в Maven   -  person Roland Weisleder    schedule 08.10.2018
comment
@RolandWeisleder - спасибо за ссылку - хотя я не смог понять, как применить ответ на этот вопрос к моей проблеме - другой вопрос кажется связанным, но гораздо более общим. Не могли бы вы помочь?   -  person flow2k    schedule 09.10.2018

Ответы (1)


arrow_upward
3
arrow_downward

Maven не позволяет иметь зависимость от нескольких версий одного и того же артефакта. Разрешение зависимостей работает следующим образом:

Maven выбирает «ближайшее определение». То есть он использует версию ближайшей к вашему проекту зависимости в дереве зависимостей. Вы всегда можете гарантировать версию, объявив ее явно в POM вашего проекта. Обратите внимание, что если две версии зависимостей находятся на одной глубине в дереве зависимостей, первое объявление выигрывает.

«ближайшее определение» означает, что используемая версия будет ближайшей к вашему проекту в дереве зависимостей. Например, если зависимости для A, B и C определены как A -> B -> C -> D 2.0 и A -> E -> D 1.0, то при построении A будет использоваться D 1.0, поскольку путь от A до D через E короче. Вы можете явно добавить зависимость от D 2.0 в A, чтобы принудительно использовать D 2.0.

Источник: Введение в Механизм зависимостей

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

  • создайте модуль «Bar-shaded», который создает затененный JAR «Bar» и все его зависимости
  • в модуле «А» добавить зависимости для «Foo» версии 1 и «Bar-shaded»
person Roland Weisleder    schedule 09.10.2018
comment
Ах... под module "Bar-shaded" вы имеете в виду, что мне нужно будет создать еще один проект/артефакт Maven (с плагином затенения), который действует как оболочка для стороннего артефакта Bar? - person flow2k; 10.10.2018
comment
@flow2k Точно - person Roland Weisleder; 11.10.2018
comment
Было бы так здорово, если бы в шейдерном плагине была опция, которая могла бы сделать это автоматически, поэтому мне не нужно создавать все эти проекты шейд-обертки (в случае, если их больше одного). Но я думаю, что функция еще не существует ... - person flow2k; 13.10.2018