3 回答
TA贡献1796条经验 获得超7个赞
但是,当我使用Maven Shade插件创建还包含项目所有依赖项的JAR时,不会自动包含第三方JAR。
是的,因为system假定范围内的依赖项始终存在(这正是system范围的含义),所以不会将它们包括在内。人们实际上不了解什么是system范围依赖,他们只是不断滥用它们(是的,这是滥用),然后产生副作用并想知道为什么(正如Brian在回答中指出的那样)。
我已经写很多,很多,真的 很多次关于这个在这里SO和在99%的情况,system范围的相关性都应当避免。我将再重复一次“ Dependency Scopes”迷你指南所说的内容:
system:在项目生命周期的某个阶段需要此依赖关系,但它是系统特定的。不建议使用此范围:这是“高级”功能,仅当您真正了解其使用的所有后果时,才可以使用它,如果实际上无法量化,则可能非常困难。根据定义,此范围使您的构建不可移植。在某些情况下可能有必要。系统范围包括<systemPath>指向此依赖项在本地计算机上的物理位置的元素。因此,它用于指代预期出现在给定本地计算机上而不是存储库中的某些工件;并且其路径可能因机器而异。systemPath元素可以在其路径中引用环境变量:${JAVA_HOME} 例如。
因此,不使用system范围,而是:
通过将库添加到本地存储库install:install-file。这是使事情正常进行的一种快速而肮脏的方法,如果您一个人,它可能是一种选择,但它会使您的构建不可移植。
安装并运行Nexus,Archiva或Artifactory等“企业存储库”,然后通过添加您的库deploy:deploy-file。这是理想的情况。
如上一个答案中所述设置基于文件的存储库,然后将您的库放入其中。如果您没有公司存储库,但需要团队协作并且不想牺牲可移植性,那么这是最好的折衷方案。
请停止使用system示波器。
TA贡献1804条经验 获得超2个赞
使用<resources>将我的lib包含在所有jar中。即:
<build>
<resources>
<resource>
<directory>${project.basedir}</directory>
<includes>
<include>lib/*.jar</include>
</includes>
</resource>
</resources>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>2.3</version>
<configuration>
<createDependencyReducedPom>false</createDependencyReducedPom>
</configuration>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
添加回答
举报