现在位置: 首页 / JAVA / 技术分享 / 正文

Maven 引入外部 JAR 包的三种实用方式

  • TiBon
  • JAVA
  • 2024-04-03
  • 142热度
  • 0评论
在 Maven 项目开发过程中，我们常会遇到需要引入非中央仓库提供的外部 JAR 包的场景，比如自研的工具包、第三方未开源的定制包等。常规的 Maven 依赖声明无法直接拉取这类 JAR 包，此时就需要通过特定方式将外部 JAR 包引入项目中。本文将详细介绍三种实操性强的 Maven 引入外部 JAR 包的方法，涵盖快速引用、编译指定、本地仓库安装三种场景，适配不同的开发需求。

方式一：通过 system 作用域直接本地引用

这是最快捷的引入外部 JAR 包的方式，通过在dependency中指定system作用域，同时配置 JAR 包的本地物理路径，让 Maven 直接识别并引用本地的 JAR 包，无需将包上传到任何仓库，适合快速测试、临时引入的场景。

核心配置

在项目的pom.xml文件中，添加如下依赖配置，核心是scope设为system，并通过systemPath指定 JAR 包的本地路径：
<dependency>
    <groupId>com.custom</groupId>  <!-- 自定义组名，无强制规范，建议按项目包名规范定义 -->
    <artifactId>custom-utils</artifactId>    <!-- 自定义项目名，标识该JAR包 -->
    <version>1.0.0</version> <!-- 自定义版本号，便于版本管理 -->
    <scope>system</scope> <!-- system作用域：Maven不会从仓库查找，需显式指定本地路径 -->
    <systemPath>${basedir}/lib/custom-utils.jar</systemPath> <!-- 本地JAR包路径，${basedir}代表项目根目录 -->
</dependency>

 

关键说明

  1. system作用域类似provided，该 JAR 包仅在编译和测试阶段生效，打包时不会默认打入最终产物（如 war/jar 包），若需要打包引入，需额外配置打包插件；
  2. 建议在项目根目录下创建lib文件夹，将外部 JAR 包统一放入，便于项目管理和团队协作；
  3. groupId、artifactId、version可自定义，无固定要求，但建议保持命名规范，与项目整体依赖命名风格一致。

方式二：编译阶段通过插件指定外部 lib 目录

这种方式无需为每个外部 JAR 包单独配置依赖，而是通过 Maven 编译插件maven-compiler-plugin，指定外部 JAR 包的统一存放目录，Maven 在编译时会自动扫描该目录下的所有 JAR 包并引入，适合需要同时引入多个外部 JAR 包的场景，简化配置步骤。

核心配置

在pom.xml的build->plugins节点中，配置maven-compiler-plugin，通过compilerArguments的extdirs指定外部 JAR 包的目录：
<build>
    <plugins>
        <plugin>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.8.1</version> <!-- 插件版本，建议使用稳定版 -->
            <configuration>
                <source>1.8</source> <!-- 项目编译JDK版本 -->
                <target>1.8</target> <!-- 项目目标JDK版本 -->
                <encoding>UTF-8</encoding> <!-- 编译编码，避免中文乱码 -->
                <compilerArguments>
                    <extdirs>lib</extdirs> <!-- 指定外部JAR包目录，项目根目录下的lib文件夹 -->
                </compilerArguments>
            </configuration>
        </plugin>
    </plugins>
</build>

 

关键说明

  1. 需将所有外部 JAR 包统一放入指定的lib目录（可自定义目录名，如external-lib），Maven 编译时会扫描该目录下所有 JAR 包，无需逐个配置；
  2. 插件版本建议选择与项目 Maven 版本兼容的稳定版，避免因版本不匹配导致编译报错；
  3. 该方式仅解决编译阶段的 JAR 包依赖问题，若项目打包时需要将外部 JAR 包打入，需额外配置maven-resources-plugin或打包插件。

方式三：将外部 JAR 包安装到本地 Maven 仓库

这是最规范、最推荐的方式，通过 Maven 命令将外部 JAR 包安装到本地 Maven 仓库（默认路径：C:\Users\用户名\.m2\repository），安装后即可像引入中央仓库的依赖一样，直接在pom.xml中通过常规dependency声明引用，适配正式开发、团队协作的场景，同时支持打包时自动引入。

操作步骤

1. 执行 Maven 安装命令

打开命令行（CMD/PowerShell/Terminal），进入外部 JAR 包的所在目录，执行以下 Maven 命令，将 JAR 包安装到本地仓库：
mvn install:install-file -Dfile=custom-utils.jar -DgroupId=com.custom -DartifactId=custom-utils -Dversion=1.0.0 -Dpackaging=jar
命令参数说明：
  • -Dfile：本地外部 JAR 包的文件名（含后缀）；
  • -DgroupId：自定义组名，与依赖配置中的groupId一致；
  • -DartifactId：自定义项目名，与依赖配置中的artifactId一致；
  • -Dversion：自定义版本号，与依赖配置中的version一致；
  • -Dpackaging：包类型，固定为jar。

2. 常规引入依赖

安装完成后，在项目pom.xml中添加普通的依赖声明即可，无需配置作用域和本地路径，Maven 会自动从本地仓库查找：
<dependency>
    <groupId>com.custom</groupId>
    <artifactId>custom-utils</artifactId>
    <version>1.0.0</version>
</dependency>

 

关键说明

  1. 该方式符合 Maven 的依赖管理规范，打包时会自动将 JAR 包打入最终产物，无需额外配置；
  2. 团队协作时，需将该 JAR 包同步安装到每个开发人员的本地仓库，或部署到公司私有 Maven 仓库（如 Nexus），让团队成员统一拉取；
  3. 若后续 JAR 包版本更新，只需重新执行安装命令指定新版本号，再修改pom.xml中的版本号即可，便于版本迭代。

三种方式对比与使用建议

引入方式 配置复杂度 适用场景 优点 缺点
system 作用域直接引用 低 临时引入、快速测试 配置简单、无需额外操作 不符合 Maven 规范，打包需额外配置，团队协作需同步 JAR 包
编译插件指定 lib 目录 中 批量引入多个外部 JAR 包 一次配置、批量引入，简化依赖代码 仅编译生效，打包需额外配置，无法单独管理单个 JAR 包版本
安装到本地 Maven 仓库 中 正式开发、团队协作、生产环境 符合 Maven 规范，打包自动引入，版本管理方便，支持私有仓库部署 需执行命令安装，团队协作需同步仓库或部署私有仓
通用使用建议：
  1. 临时测试、快速验证功能：使用方式一；
  2. 本地开发需批量引入多个外部 JAR 包：使用方式二；
  3. 正式开发、团队协作、项目打包部署：优先使用方式三，若团队规模较大，建议将外部 JAR 包部署到公司私有 Maven 仓库，替代本地安装，提升协作效率。