流行方法的问题
您在互联网上找到的大多数答案都会建议您将依赖项安装到本地存储库,或者在其中指定 \'system\' 范围, pom
并将依赖项与项目源一起分发。但这两种解决方案实际上都是有缺陷的。
为什么你不应该采用“安装到本地存储库”方法
当您将依赖项安装到本地存储库时,它会保留在那里。只要您的分发工件可以访问此存储库,它就可以正常工作。问题是,在大多数情况下,此存储库将驻留在您的本地计算机上,因此无法在任何其他计算机上解决此依赖关系。显然,让您的工件依赖于特定机器并不是解决问题的方法。否则,必须在使用该项目的每台机器上本地安装此依赖项,这并不是更好的选择。
为什么你不应该采用“系统范围”方法
使用“系统范围”方法所依赖的 jar 既不会安装到任何存储库,也不会附加到目标包。这就是为什么您的分发包在使用时无法解决该依赖关系的原因。我相信这就是系统范围的使用甚至被弃用的原因。无论如何,您都不想依赖已弃用的功能。
项目内静态存储库解决方案
将其放入您的 pom
:
<repository>
<id>repo</id>
<releases>
<enabled>true</enabled>
<checksumPolicy>ignore</checksumPolicy>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
<url>file://${project.basedir}/repo</url>
</repository>
对于每个具有组 ID 的工件, x.y.z
Maven 将在其工件搜索中包含项目目录中的以下位置:
repo/
| - x/
| | - y/
| | | - z/
| | | | - ${artifactId}/
| | | | | - ${version}/
| | | | | | - ${artifactId}-${version}.jar
要详细阐述这一点,你可以阅读 此博客文章 .
使用 Maven 安装到项目仓库
我建议不要手动创建此结构,而是使用 Maven 插件将您的 jar 作为工件安装。因此,要将工件安装到 repo
文件夹下的项目内存储库,请执行:
mvn install:install-file -DlocalRepositoryPath=repo -DcreateChecksum=true -Dpackaging=jar -Dfile=[your-jar] -DgroupId=[...] -DartifactId=[...] -Dversion=[...]
如果您选择这种方法,您将能够将存储库声明简化为 pom
:
<repository>
<id>repo</id>
<url>file://${project.basedir}/repo</url>
</repository>
帮助脚本
由于执行每个库的安装命令有点烦人,而且肯定容易出错,所以我创建了一个 实用程序脚本 ,它会自动将文件夹中的所有 jar 安装 lib
到项目存储库,同时自动从文件名称解析所有元数据(groupId、artifactId 等)。该脚本还会打印出依赖项 xml,供您复制粘贴到您的 pom
.
在目标包中包含依赖项
当您创建项目内的存储库时,您将解决使用其源分发项目依赖项的问题,但从那时起,您的项目的目标工件将依赖于未发布的 jar,因此当您将其安装到存储库时,它将具有无法解析的依赖项。
为了解决这个问题,我建议将这些依赖项包含在目标包中。您可以使用 Assembly 插件 或更好的 OneJar 插件 。OneJar 的官方文档很容易掌握。