底纹功能应用程序所需的相同依赖项的多个版本

我有一个多项目应用程序，我们使用一个库，oshi，依赖于版本4.2.2的JNA。在我们的项目本身，我们使用4.3.0，它还没有发布。我们在4.3.0版本发布时做出了贡献，但我们现在需要它，所以我们目前使用我们自己构建的分叉版本。底纹功能应用程序所需的相同依赖项的多个版本

我们使用maven遮罩插件打包所有东西。目前，阴影插件在uberjar中使用4.3.0。

问题是，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

谁能给我如何解决这个有什么建议？谢谢！

来源

2016-12-07 Kevin Milner

通过重新定位你的意思从一个模块移动所述罐到另一个？或者这到底意味着什么？你也可以分享你最终在你的pom中使用'oshi'和定制'JNA'的最小依赖关系。 – nullpointer

我在回复中更新了问题。 –

如果这两个实现相互冲突，为什么要在这种情况下使用这两个依赖项？ – nullpointer

你所寻找的可能是<includes>执行maven的遮阳帘插件作为documented here

当然，<includes>可以作为很好的指定文物白名单。伪影由形式为的组合标识符表示。由于插件版本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>

来源

2016-12-07 19:55:05 nullpointer

问题不在于包括依赖关系，而是uberjar中的依赖类文件存储在./net/java/dev/jna/目录中。由于没有办法指定版本，并且类文件具有相同的名称，无论哪个写入最后获胜。为了什么它的价值，打破一切的变化似乎是在这里： https://github.com/java-native-access/jna/commit/61bd36b0d05d18008377cd9d011be0c794f86296 –

底纹功能应用程序所需的相同依赖项的多个版本

回答

相关问题