前言

在使用Maven管理Java项目时，有时需要引入一些存放在系统特定位置的JAR文件。这些JAR文件可能是你自己编写的，也可能是其他来源的。无论是哪种情况，使用 Maven 的 system 范围和 systemPath 参数，可以方便地引入这些本地依赖。

仓库分类

在Java开发中，Maven是非常重要的构建工具，他的仓库机制用于存储和管理项目的依赖。Maven仓库大致可以分为两类：本地仓库和远程仓库。

本地仓库

本地仓库是开发者本地机器上的仓库，所有下载的或者由Maven构建生成的项目的构件（artifact）都存储在这里。这种仓库只能被你的Maven客户端访问。

本地仓库的位置

Maven本地仓库默认情况下位于当前用户的主目录下的.m2目录，即“C:\Users{用户名}.m2\repository”这个位置，这个本地仓库用于存储Maven下载的所有依赖库文件。

修改对应的本地仓库位置

通过更改Maven的全局设置文件settings.xml来改变本地仓库的位置。这个文件位于你Maven安装目录的conf目录下。在settings.xml文件中，你可以找到localRepository这个标签，该标签默认会被注释掉，移除注释并设置新的路径就可以改变本地仓库的位置。

在开发过程中，如果你有一个Java项目或模块（比如一个构建了的jar文件），想把它作为一个本地的依赖供其他项目或模块使用，你可以通过Maven的Install插件来做到这一点。Install插件负责将项目构件安装到本地仓库，《mvn clean install》这条命令将会清除目标目录下的旧版本构建文件，然后生成新的构建文件，并将其安装到本地仓库。这样，其他依赖此构件的模块便能从本地仓库中获取到这个依赖，从而进行进一步的构建和开发。

远程仓库

远程仓库是部署在web服务器上的，可以被多个构建项目共享。

远程仓库的种类

远程仓库主要包括下列三种：

• 中央仓库：Maven 中央仓库是一个由Maven社区维护的，项目中通常都会用到的开源构建会被发布到此处。Maven 会默认从该仓库获取依赖包，不需要进行额外配置。
  
• 私服仓库：如果发现从中央仓库下载构建过慢，或者需要存储公司内部的专有构建，可以配置私有仓库（如Nexus或Artifactory）。
  
• 其他仓库：除了Maven中央仓库以外还有其他第三方维护的公共库，这些库里面可能会包含中央仓库中没有的一些依赖包。
  

依赖搜索顺序

Maven的搜索顺序是先本地仓库，然后再远程仓库，而远程仓库中，先搜索私服，其次才是中央仓库和其他公共库，这样的安排既保证了优先使用本地资源，节省了宽带，也能保证依赖库的及时更新。

使用system scope+systemPath

Maven使用system范围与systemPath参数来引用本地的JAR文件。

system scope的作用

当使用 system scope 指定依赖时，Maven会在系统中查找已经存在的该依赖，如果存在则直接使用，避免再次去远程仓库中查找。然而，如果该依赖在系统中不存在，后续操作依然会失败。因此，在使用 system 范围引入依赖之前，确保该依赖在你的系统中存在。这是一个需要注意的问题。

systemPath的作用

systemPath 参数用于指定依赖在系统中的绝对路径，这样 Maven 在编译时就可以直接使用这个路径来查找依赖。如果同一个依赖在工程中多次使用，重复指定 systemPath 参数比较繁琐。为了避免这种情况，可以考虑使用 Maven 的 project.parent 或 dependencyManagement 来进行统一管理。这样可以将依赖的版本、scope 等信息放在一个地方进行管理，使得项目结构更加清晰和易于维护。在实际项目中，这种方式往往会提高开发效率，减少错误的发生。

使用案例

Maven项目中的一个 dependencies 配置，用于指定项目需要依赖的外部 jar 包。具体来说，这个配置中指定了一个 groupId 为 com.liboware，artifactId 为 my-jar，version 为 1.0 的外部 jar 包，并且给这个依赖设置了系统作用域（scope），同时指定了这个 jar 包在本地文件系统中的路径。

依赖的引入

xml

复制代码

<dependencies>
    <dependency>
      <groupId>com.liboware</groupId>
      <artifactId>my-jar</artifactId>
      <version>1.0</version>
      <scope>system</scope>
      <systemPath>${project.basedir}/lib/my-jar.jar</systemPath>
    </dependency>
  </dependencies>

scope属性的取值分别有 compile、provided、runtime、test 和 system，分别表示依赖在编译、运行、测试中的作用域，而 system 则表示不需要从 Maven 仓库中下载，而是直接使用本地系统中 jar 包的路径，适用于一些本地 jar 包的使用场景。在本例中，使用了 system 作用域，并指定了本地 jar 包的路径为 ${project.basedir}/lib/my-jar.jar。

所引发的隐患问题

这种配置方式比较灵活，适用于一些需要使用本地 jar 包的场景，但同时也存在一些问题。由于使用 system 作用域时，Maven 不再管理依赖 jar 包的版本信息，这可能会导致不同版本的 jar 包之间冲突的问题，因此需要额外的注意依赖 jar 包的版本号和文件路径的正确性。

打包处理插件

当使用 Maven 的打包插件 jar-with-dependencies 打包时，使用system作用域引入的依赖包将不会被包含在输出的可执行 jar 文件中。如果需要将本地依赖包打入可执行 jar 文件中，可以通过 Maven 的resources标签进行配置。

xml

复制代码

<build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-shade-plugin</artifactId>
        <executions>
          <execution>
            <id>make-assembly</id>
            <phase>package</phase>
            <goals>
              <goal>shade</goal>
            </goals>
            <configuration>
              <descriptorRefs>
                <descriptorRef>jar-with-dependencies</descriptorRef>
              </descriptorRefs>
              <finalName>xxx-jar-with-dependencies</finalName>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
     <resources>
      <resource>
        <targetPath>lib/</targetPath>
        <directory>lib/</directory>
        <includes>
          <include>**/*.jar</include>
        </includes>
      </resource>
    </resources>
  </build>

这段 Maven 配置主要实现了使用 maven-shade-plugin 插件打包项目，并将依赖的第三方库和应用程序代码打包在一个可执行的 jar 文件中。同时，还将本地依赖包 *.jar 打包进可执行 jar 文件中。

具体来说，该配置包含以下内容：

• maven-shade-plugin 插件配置：该插件用于打包和重写 jar 文件

• descriptorRefs：指定打包类型，这里配置为 jar-with-dependencies，表示打出包含依赖的 jar 包
• finalName：指定可执行 jar 包的文件名

• resources 配置：将本地依赖包打包进 jar 文件中

• targetPath：指定本地依赖包在 jar 中的存储路径
• directory：指定本地依赖包的存储路径
• includes：指定需要打包进 jar 文件中的本地依赖包

总的来说，这个配置文件展示了一个简单的 Maven 打包过程的流程，通过 maven-shade-plugin 插件实现了将项目及其依赖（包括本地依赖包）打包在一个 jar 文件中的需求。

打包结果以及效果

生成的 xxx-jar-with-dependencies.jar 将会包含 lib 目录以及其中的 *.jar 文件，该 jar 包在执行时可以找到这些依赖包。

但有时这种方法可能会失效，比如在声明 JDBCDriver 时，使用 Class.forName("xxx.Driver") 时可能会报类找不到的错误。此时可以使用以下两种方法来解决：

• 将依赖的 JDBC 驱动包作为单独的依赖项，在运行时通过 -cp 参数指定类路径，例如：java -cp xxx-jar-with-dependencies.jar:mysql-connector-java-8.0.25.jar com.example.Main
• 将依赖的 JDBC 驱动包打包进 xxx-jar-with-dependencies.jar，并在运行时手动调用 ClassLoader 加载该依赖包中的类。

使用mvn install:install-file

可以使用以下命令将 .jar 包安装到本地 Maven 仓库中：

ini

复制代码

mvn install:install-file -Dfile=my-jar.jar -DgroupId=com.liboware -DartifactId=my-jar -Dversion=1.0 -Dpackaging=jar

其中：

• -Dfile：指定要安装的 .jar 文件的位置和文件名。
• -DgroupId：指定 Maven 项目的 GroupId。
• -DartifactId：指定 Maven 项目的 ArtifactId。
• -Dversion：指定 Maven 项目的版本号。
• -Dpackaging：指定 Maven 项目的打包方式（例如：jar、war、pom 等）。

添加 in project repository

如果你希望在一个新机器上执行 Maven 项目时不用运行 mvn install:install-file 命令，你可以将你的 .jar 包添加到项目的本地仓库中。

在项目的 pom.xml 文件中，可以声明一个 <repositories> 元素来定义项目的本地仓库。例如：

xml

复制代码

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

在上面的示例中，我们定义了一个 my-local-repository 的仓库，它的 URL 是 ${project.basedir}/lib，也就是项目的 lib 文件夹。

现在，你可以将你的 .jar 包放到项目的 lib 文件夹下，当你执行 Maven 命令时，Maven 就会从这个 my-local-repository 仓库中查找你的 .jar 包了。

xml

复制代码

<dependency>
    <groupId>com.liboware</groupId>
    <artifactId>my-jar</artifactId>
    <version>1.0</version>
</dependency>

你的jar包及路径必须严格遵循格式：

bash

复制代码

/groupId/artifactId/version/artifactId-verion.jar

本例中：lib/com/liboware/my-jar/1.0/my-jar-1.0.jar

内容总结

Maven中，可用system范围和systemPath参数引用本地.jar文件，或使用mvn install:install-file命令安装到本地仓库。为了省去在新机器上安装的麻烦，需在pom.xml文件中声明<repositories>元素指定本地仓库路径，以便Maven自动查找依赖。