可以通过声明排除依赖项中的工件<exclusions>
a 内的元素<dependency>
但在这种情况下,需要排除从父项目继承的工件。正在讨论的 POM 摘录如下:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>test</groupId>
<artifactId>jruby</artifactId>
<version>0.0.1-SNAPSHOT</version>
<parent>
<artifactId>base</artifactId>
<groupId>es.uniovi.innova</groupId>
<version>1.0.0</version>
</parent>
<dependencies>
<dependency>
<groupId>com.liferay.portal</groupId>
<artifactId>ALL-DEPS</artifactId>
<version>1.0</version>
<scope>provided</scope>
<type>pom</type>
</dependency>
</dependencies>
</project>
base
工件,取决于javax.mail:mail-1.4.jar
, and ALL-DEPS
依赖于同一库的另一个版本。由于这个事实mail.jar
from ALL-DEPS
存在于执行环境中,虽然没有导出,但与mail.jar
存在于父级上,其范围为compile
.
一个解决方案可能是从父 POM 中删除 mail.jar,但大多数继承 base 的项目都需要它(就像 log4j 的传递依赖项一样)。所以我想做的就是简单地从子项目中排除父级的库,因为如果base
是一个依赖项,而不是父 pom:
...
<dependency>
<artifactId>base</artifactId>
<groupId>es.uniovi.innova</groupId>
<version>1.0.0</version>
<type>pom<type>
<exclusions>
<exclusion>
<groupId>javax.mail</groupId>
<artifactId>mail</artifactId>
</exclusion>
</exclusions>
</dependency>
...
一些想法:
在这种情况下,也许您可以简单地不从父级继承(并声明对base
与排除)。如果父 pom 中有很多东西,就不方便了。
另一件要测试的事情是声明mail
具有所需版本的工件ALL-DEPS
在下面dependencyManagement
在父 pom 中强制收敛(尽管我不确定这会解决范围问题)。
<dependencyManagement>
<dependencies>
<dependency>
<groupId>javax.mail</groupId>
<artifactId>mail</artifactId>
<version>???</version><!-- put the "right" version here -->
</dependency>
</dependencies>
</dependencyManagement>
- 或者你可以排除
mail
如果您不使用依赖于它的功能,则来自 log4j 的依赖项(这就是我要做的):
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.15</version>
<scope>provided</scope>
<exclusions>
<exclusion>
<groupId>javax.mail</groupId>
<artifactId>mail</artifactId>
</exclusion>
<exclusion>
<groupId>javax.jms</groupId>
<artifactId>jms</artifactId>
</exclusion>
<exclusion>
<groupId>com.sun.jdmk</groupId>
<artifactId>jmxtools</artifactId>
</exclusion>
<exclusion>
<groupId>com.sun.jmx</groupId>
<artifactId>jmxri</artifactId>
</exclusion>
</exclusions>
</dependency>
- 或者您可以恢复到 log4j 的 1.2.14 版本,而不是异端的 1.2.15 版本(为什么他们不将上述依赖项标记为optional?!).
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)