流行方法的问题
在互联网上找到的大多数答案都会建议您将依赖项安装到本地存储库中,或者在pom中指定“系统”作用域,并将依赖项与项目的源代码一起分发。但这两种解决方案实际上都有缺陷。
为什么你不应该应用“安装到本地回购”的方法
When you install a dependency to your local repository it remains there. Your distribution artifact will do fine as long as it has access to this repository. The problem is in most cases this repository will reside on your local machine, so there'll be no way to resolve this dependency on any other machine. Clearly making your artifact depend on a specific machine is not a way to handle things. Otherwise this dependency will have to be locally installed on every machine working with that project which is not any better.
为什么不应该应用“系统范围”方法
使用“System Scope”方法依赖的jar既不能安装到任何存储库中,也不能附加到目标包中。这就是为什么你的发行包在使用时没有办法解决这个依赖。我相信这就是为什么不提倡使用系统作用域的原因。无论如何,你不想依赖一个已弃用的特性。
静态项目内存储库解决方案
把这个放进你的诗里后:
<repository>
<id>repo</id>
<releases>
<enabled>true</enabled>
<checksumPolicy>ignore</checksumPolicy>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
<url>file://${project.basedir}/repo</url>
</repository>
对于每个具有x.y.z形式的组id的工件,Maven将在其搜索工件时在您的项目目录中包含以下位置:
repo/
| - x/
| | - y/
| | | - z/
| | | | - ${artifactId}/
| | | | | - ${version}/
| | | | | | - ${artifactId}-${version}.jar
要详细说明这一点,你可以阅读这篇博文。
使用Maven安装到项目repo
我建议使用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>
辅助脚本
由于为每个lib执行安装命令有点烦人,而且肯定容易出错,所以我创建了一个实用程序脚本,它自动将lib文件夹中的所有jar安装到项目存储库中,同时从文件名自动解析所有元数据(groupId, artifactId等)。该脚本还打印出依赖项xml,供您复制粘贴到pom中。
在目标包中包含依赖项
当您创建了项目内存储库时,您就解决了项目与其源的依赖关系分布问题,但是从那时起,项目的目标工件将依赖于未发布的jar,因此当您将其安装到存储库时,它将具有无法解决的依赖关系。
为了解决这个问题,我建议在目标包中包含这些依赖项。这可以用Assembly Plugin或者更好的OneJar Plugin来实现。OneJar的官方文档很容易掌握。