如何在Maven中央仓库发布时引入无法获取的外部JAR包？

方案1：随项目打包外部JAR并指导用户安装到本地仓库 #

• 可行性：完全可行，但用户体验较差。你可以把这些JAR放在项目的src/main/resources/lib或独立的lib目录下，在INSTALL文档里明确给出本地仓库安装命令，比如：

  mvn install:install-file -Dfile=lib/xxx.jar -DgroupId=原包groupId -DartifactId=原包artifactId -Dversion=原包版本 -Dpackaging=jar
  

  但要注意，用户必须手动执行这些步骤才能构建项目，这会抬高使用门槛，尤其是自动化构建场景（如CI/CD）会更繁琐，每次构建都要先处理这些依赖。
• 合规注意：必须确认这些JAR的开源许可证允许重新分发，比如MIT、Apache 2.0这类宽松许可证没问题；如果是GPLv3等强 copyleft 许可证，要确保你的项目许可证与之兼容，同时明确告知用户这些依赖的来源和许可证信息。

方案2：自行上传外部JAR到Maven仓库（用自身groupId但不修改内容） #

• 伦理与合规性：需分情况判断：
  • 如果原开源项目许可证允许重新分发（大部分开源许可证都支持），这种操作合规但不推荐。上传时必须严格保留原包的所有版权声明、许可证文件，并且在你的groupId下明确标注这是原项目的分发镜像，比如用com.yourgroup.mirror.原项目groupId的结构，避免用户混淆为你维护的版本。
  • 但Maven中央仓库有严格规范，用自身groupId上传他人代码可能被判定为“冒充”或不符合命名规范，甚至面临下架风险。更稳妥的方式是：
    1. 尝试联系原项目作者，请求他们上传到Maven中央仓库，或提交PR协助完成上传流程。
    2. 若联系不上作者，可fork原项目，用自身groupId上传fork后的版本，同时明确标注这是fork版，并保留原项目所有版权信息。
• 风险提示：若原项目后续正式上传到Maven中央仓库，你的分发版可能与官方版本冲突，导致用户依赖混乱。

更优替代方案 #

• 使用Maven自动安装插件：配置maven-install-plugin，让项目构建时自动将lib目录下的JAR安装到本地仓库，用户只需执行mvn install即可自动处理依赖，无需手动敲命令。配置示例：

  <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-install-plugin</artifactId>
      <version>3.1.0</version>
      <executions>
          <execution>
              <id>install-external-jar</id>
              <phase>initialize</phase>
              <goals>
                  <goal>install-file</goal>
              </goals>
              <configuration>
                  <file>${project.basedir}/lib/xxx.jar</file>
                  <groupId>原包groupId</groupId>
                  <artifactId>原包artifactId</artifactId>
                  <version>原包版本</version>
                  <packaging>jar</packaging>
              </configuration>
          </execution>
      </executions>
  </plugin>
  

• 搭建私有Maven仓库：用Nexus或Artifactory搭建私有仓库，将这些外部JAR上传至私有仓库后，在项目pom.xml中添加私有仓库地址，用户只需配置该私有仓库即可自动拉取依赖。但这种方案需要你持续维护私有仓库，适合团队内部或有一定用户量的项目。

内容的提问来源于stack exchange，提问作者Arend