使用 JitPack 托管 Spring Boot Starter，实现跨项目的通用模块统一管理-泡泡吐puber

在常规的 Java 开发流程中，开发者完成 Starter 开发后，通常执行 mvn install 将其安装至本地 .m2 仓库。这种方式在单人开发场景下尚可运行，但在团队协作和 CI/CD 流水线中会暴露出严重的物理局限性。故而推荐的做法是将本地组件托管至云端，使其像标准开源库一样，通过 Maven 坐标即可随处引用。

1. 方案概述

JitPack 提供了一种基于 Git 仓库的即时构建发布方案。它允许开发者直接使用 Git 的发行版（Release）或分支作为版本号，无需额外部署和维护 Maven 私服，即可通过标准的 Maven 坐标在任何项目中引用私有组件。

本文将演示如何将一个本地开发的 Starter 组件，通过标准化配置推送到 GitHub，并利用 JitPack 转化为可被 Maven 识别的云端依赖。

2. Starter 项目规范化配置

在将 Starter 推送至云端之前，必须确保项目符合标准的 Maven 构建规范，以便 JitPack 能够正确编译和打包。

2.1 坐标定义

在 pom.xml 中明确 GroupId、ArtifactId 与 Version。为了适配 JitPack 的规则，GroupId 建议与 GitHub 用户名保持映射关系。

<groupId>com.github.wenlishi</groupId>
<artifactId>trajectory-spring-boot-starter</artifactId>
<version>1.0.0</version>

2.2 构建插件优化

Starter 项目属于依赖库，不需要打成可执行的 JAR 包（即不包含 Main-Class）。因此需配置 spring-boot-maven-plugin 跳过 repackage 阶段。同时，为了避免 JDK 8+ 环境下的 Javadoc 严格检查导致构建中断，建议放宽 Javadoc 限制。

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <configuration>
                <skip>true</skip>
            </configuration>
        </plugin>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-javadoc-plugin</artifactId>
            <configuration>
                <failOnError>false</failOnError>
                <doclint>none</doclint>
            </configuration>
        </plugin>
    </plugins>
</build>

3. GitHub 版本发布流程

JitPack 的构建机制深度集成于 Git 的 Tag（标签）系统。

代码提交：确保所有功能代码已提交并推送到 GitHub main 分支。
创建 Release：
- 进入 GitHub 仓库主页，点击右侧 Releases。
- 点击 Draft a new release。
- Tag version：输入语义化版本号（例如 v1.0.0），这将成为 Maven 坐标的版本号。
- Target：选择 main 分支。
- 点击 Publish release。

完成此步骤后，GitHub 上将生成对应的 Tag，JitPack 将以此为锚点进行后续的构建工作。

4. JitPack 构建与验证

访问 JitPack.io。
在搜索框输入 GitHub 仓库地址（格式：用户名/仓库名，如 wenlishi/trajectory-spring-boot-starter）。
点击 Look up。
在版本列表中找到刚才发布的 v1.0.0，点击 Get it。
状态确认：
- 观察 Log 列的图标。
- 绿色：构建成功，制品已准备就绪。
- 红色：构建失败，需点击图标查看详细 Maven 日志进行排查（通常是编译错误或 Javadoc 配置问题）。

5. 客户端集成方案

在业务项目中引用该 Starter，需要进行仓库源和依赖的配置。

5.1 配置 Maven 仓库

由于该组件托管在 JitPack，需要在 pom.xml 中显式添加 JitPack 仓库地址：

<repositories>
    <repository>
        <id>jitpack.io</id>
        <url>https://jitpack.io</url>
    </repository>
</repositories>

5.2 引入依赖

使用 JitPack 生成的标准坐标进行引用：

<dependency>
    <groupId>com.github.wenlishi</groupId>
    <artifactId>trajectory-spring-boot-starter</artifactId>
    <version>v1.0.0</version>
</dependency>

以上的配置信息 Jitpack 会帮我们自动生成，点击Get it ，然后页面会自动下滑，展示出对应的starter的配置信息。

然后选择我们所需要的格式。

6. 环境适配：解决镜像代理冲突

在国内开发环境下，开发者通常会在 Maven 的 settings.xml 中配置阿里云镜像加速 (aliyunmaven)。默认的 <mirrorOf>*</mirrorOf> 配置会导致 Maven 强制从阿里云下载所有依赖，从而忽略项目级 pom.xml 中配置的 jitpack.io 仓库，导致 ArtifactNotFoundException。所以还修改 Maven 的 settings.xml 文件，在镜像配置中显式排除 JitPack。将<mirrorOf>*</mirrorOf> 改成 <mirrorOf>*,!jitpack.io</mirrorOf>。

<mirror>
    <id>aliyunmaven</id>
    <mirrorOf>*,!jitpack.io</mirrorOf>
    <name>阿里云公共仓库</name>
    <url>https://maven.aliyun.com/repository/public</url>
</mirror>

修改完成后，在项目中执行 mvn clean install -U 强制更新依赖，即可成功拉取云端组件。

7. 版本迭代与不可变性原则

在组件维护过程中，严禁修改已发布版本的代码（例如删除 Git Tag 重新发布）。这是因为 JitPack 和本地 Maven 都会对构建产物进行强缓存。

当 Starter 代码发生变更（Bug 修复或功能新增）时，必须遵循语义化版本控制流程：

修改 Starter 版本：在 Starter 项目的 pom.xml 中将版本号升级（例如从 1.0.0 升级为 1.0.1）。
提交代码：将修改推送至 GitHub。
发布新 Release：在 GitHub 上创建新的 Release（Tag: v1.0.1）。
客户端升级：在业务项目中，修改 dependency 的版本号为新版本 v1.0.1 并刷新 Maven。

遵循此规范可确保团队成员和线上环境使用的依赖始终是确定且一致的。

目录CONTENT

使用 JitPack 托管 Spring Boot Starter，实现跨项目的通用模块统一管理