2016-12-07 18 views
1

У меня есть многопроектное приложение, в котором мы используем библиотеку oshi, которая зависит от версии 4.2.2 от JNA. В нашем проекте мы используем 4.3.0, который еще не выпущен. Мы внесли вклад, который будет в версии 4.3.0, когда он будет выпущен, но нам это нужно прямо сейчас, поэтому в настоящее время мы используем раздвоенную версию, которую мы создаем сами.Затенение нескольких версий одинаковых зависимостей, необходимых для функционирования приложения

Мы упаковываем все, используя плагин maven shade. В настоящее время теневой плагин использует 4.3.0 в uberjar.

Проблема в том, что oshi использует функцию в 4.2.2, которая, похоже, не в 4.3.0. Интерфейс, который мы используем, был изменен, и теперь мы получаем исключение NoSuchMethodError. Исключение мы получаем следующий вид:

org.quartz.JobExecutionException: org.quartz.SchedulerException: Job threw an unhandled exception. [See nested exception: java.lang.NoSuchMethodError: com.sun.jna.platform.win32.OleAuto.VariantClear(Lcom/sun/jna/Pointer;)Lcom/sun/jna/platform/win32/WinNT$HRESULT;] 
at org.quartz.core.JobRunShell.run(JobRunShell.java:218) [quartz-2.2.3.jar:?] 
at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:573) [quartz-2.2.3.jar:?] 

Caused by: org.quartz.SchedulerException: Job threw an unhandled exception. 
at org.quartz.core.JobRunShell.run(JobRunShell.java:213) [quartz-2.2.3.jar:?] 
... 1 more 
Caused by: java.lang.NoSuchMethodError: com.sun.jna.platform.win32.OleAuto.VariantClear(Lcom/sun/jna/Pointer;)Lcom/sun/jna/platform/win32/WinNT$HRESULT; 
at oshi.util.platform.windows.WmiUtil.enumerateProperties(WmiUtil.java:504) ~[oshi-core-3.2.jar:3.2] 
at oshi.util.platform.windows.WmiUtil.queryWMI(WmiUtil.java:304) ~[oshi-core-3.2.jar:3.2] 
at oshi.util.platform.windows.WmiUtil.selectUint32sFrom(WmiUtil.java:112) ~[oshi-core-3.2.jar:3.2] 
at oshi.hardware.platform.windows.WindowsGlobalMemory.updateSwap(WindowsGlobalMemory.java:74) ~[oshi-core-3.2.jar:3.2] 
at oshi.hardware.common.AbstractGlobalMemory.getSwapTotal(AbstractGlobalMemory.java:82) ~[oshi-core-3.2.jar:3.2] 

Так что мне нужно сделать, это выяснить, как иметь обе версии в uberjar.

Я пробовал relocating версию 4.3.0, но она, похоже, не работала (классы не были в uberjar в любом месте). Далее я клянусь, что сегодня я читал (но, конечно, не могу найти его сейчас), что шаблон в поле перемещения - groupId:artifactId[:type][:classifier] без опции для версии.

Соответствующая часть моего дерева зависимостей выглядит следующим образом:

myproject 
+-oshi-core 
| +- jna 4.2.2 
+-jna 4.3.0-CUSTOM 

Может кто-нибудь дать мне какие-либо предложения о том, как решить эту проблему? Спасибо!

+0

Перемещая вы имеете в виду перемещения банки от одного модуля другому? Или что это значит? Также вы можете делиться минимальными зависимостями, которые вы, наконец, попадаете в ваш pom как с 'oshi', так и с настройкой' JNA', пожалуйста. – nullpointer

+0

Я обновил вопрос в ответ. –

+0

Если обе эти реализации конфликтуют друг с другом, почему вы хотите использовать обе зависимости в этом случае? – nullpointer

ответ

0

То, что вы ищете, вероятно, <includes> реализации Maven-тень-плагин, как documented here

Конечно, <includes> может также использоваться для указания белого списка артефактов. Артефакты обозначаются композитным идентификатором вида groupId:artifactId[[:type]:classifier]. Начиная с версии 1.3 плагина, подстановочные символы '*' и '?' можно использовать, чтобы сделать glob-подобный рисунок сопоставив.

Для мелкозернистого управления которого классы от выбранных зависимостей включены, может быть использован артефакт фильтры:

например

<configuration> 
    <filters> 
     <filter> 
      <artifact>com.github.dblock:oshi-core</artifact> 
      <includes> 
       <include><!--some package you want to include here--></include> 
      </includes> 
     </filter> 
     <filter> 
      <artifact>net.java.dev.jna:jna</artifact> 
      <includes> 
       <include><!--the package from 4.2.0 you want to keep--></include> 
      </includes> 
      </filter> 
     </filters> 
</configuration> 
+0

проблема заключается не столько в зависимости от зависимости, но в том, что файлы класса зависимостей в uberjar хранятся в каталоге ./net/java/dev/jna/. Поскольку нет способа указать версию, а файлы классов имеют одно и то же имя, в зависимости от того, какая из последних побед. Для чего его стоит изменение, которое ломает все, как представляется, находится здесь: https://github.com/java-native-access/jna/commit/61bd36b0d05d18008377cd9d011be0c794f86296 –