你可以使用eclipse生成一个可运行的Jar: 导出/Runable Jar文件

我也遇到了同样的问题，它只需要删除DlocalRepositoryPath参数，并在Dfile参数中从当前位置定义正确的路径即可:

mvn install:install-file -Dfile=./repo/com/tridion/cd_core/1.0/cd_core-1.0.jar -DgroupId=com.tridion -DartifactId=cd_core -Dversion=1.0 -Dpackaging=jar

注意:Apache Maven 3.8.6

使用系统作用域。${basedir}是pom的目录。

<dependency>
    <artifactId>..</artifactId>
    <groupId>..</groupId>
    <scope>system</scope>
    <systemPath>${basedir}/lib/dependency.jar</systemPath>
</dependency>

然而，建议您将jar安装在存储库中，而不是提交给SCM——毕竟这是maven试图消除的。

我以前曾经写过这样做的模式。

它与Pascal提出的解决方案非常相似，不过它将所有依赖项移动到一个专用的存储库模块中，这样如果是多模块构建，就不必在使用依赖项的所有地方重复它。

我希望jar在源代码控制的3rdparty库中，并通过相对路径从pom.xml文件链接到它。

如果您真的想要这样做(请理解，如果您不能使用公司存储库)，那么我的建议是使用项目本地的“文件存储库”，并且不要使用系统范围的依赖项。应该避免系统作用域，这种依赖关系在很多情况下(例如在汇编中)都不能很好地工作，它们带来的麻烦多于好处。

因此，相反，在项目本地声明一个存储库:

<repositories>
  <repository>
    <id>my-local-repo</id>
    <url>file://${project.basedir}/my-repo</url>
  </repository>
</repositories>

使用Install: Install -file和localRepositoryPath参数安装第三方lib:

mvn install:install-file -Dfile=<path-to-file> -DgroupId=<myGroup> \ 
                         -DartifactId=<myArtifactId> -Dversion=<myVersion> \
                         -Dpackaging=<myPackaging> -DlocalRepositoryPath=<path>

更新:当使用2.2版本的插件时，install:install-file似乎忽略了localRepositoryPath。但是，它适用于该插件的2.3及更高版本。所以使用插件的完全限定名来指定版本:

mvn org.apache.maven.plugins:maven-install-plugin:2.3.1:install-file \
                         -Dfile=<path-to-file> -DgroupId=<myGroup> \ 
                         -DartifactId=<myArtifactId> -Dversion=<myVersion> \
                         -Dpackaging=<myPackaging> -DlocalRepositoryPath=<path>

maven-install-plugin文档

最后，像其他依赖一样声明它(但是没有系统作用域):

<dependency>
  <groupId>your.group.id</groupId>
  <artifactId>3rdparty</artifactId>
  <version>X.Y.Z</version>
</dependency>

在我看来，这是一个比使用系统作用域更好的解决方案，因为您的依赖项将被视为一个好公民(例如，它将包含在一个程序集中等等)。

现在，我必须提到在企业环境中处理这种情况的“正确方法”(这里可能不是这样)是使用企业存储库。

你可以使用eclipse生成一个可运行的Jar: 导出/Runable Jar文件