002-maven仓库

使用 nexus3 配置 maven 私有仓库 ¶

（一）创建 Repository ¶

1. 创建 Blob Store ¶

创建 maven-devops	创建 maven-devops

2. 创建 hosted 类型的 maven。 ¶

在企业开发中，会开发很多内部使用的库，比如自定义的工具类库、业务组件库等。这些内部私有依赖不会发布到公共的 Maven 中央仓库。通过创建 hosted 类型的 Maven 仓库，可以将这些内部私有依赖存储在内部仓库中，方便团队内的项目引用。这样，团队成员在构建项目时，Maven 就能从这个内部仓库获取所需的私有依赖，而不需要通过其他复杂的方式来共享和管理这些依赖。

"点击 Repository -- Repositories -- Create repository -– maven2(hosted) "

配置项	操作 / 说明
Name	填写 `maven-local`，用于自定义仓库标识，方便后续管理区分。
Online	勾选，控制仓库是否处于可访问状态，勾选后 Maven 能正常与该仓库交互，取消则进入离线模式。
Maven2 版本策略	保持默认，包含三种策略： - Releases：仅存正式发布版依赖（如 `1.0.0`）； - Snapshot：仅存快照版依赖（如 `1.0.0-SNAPSHOT`）； - Mixed：混合存储前两者。
Storage - Blob store	下拉选择此前创建的专用 blob 存储 `maven-devops`，实现依赖文件的隔离存储，便于后续管理。
Hosted - Deployment policy	选择 `Allow redeploy`，因开发环境需支持重复发布相同版本依赖，满足迭代更新需求，若选默认的 `Disable redeploy` 会导致版本冲突。

3. 创建一个 proxy 类型的 maven 仓库。 ¶

Proxy 类型 Maven 仓库是企业 Maven 环境的 “基础组件”—— 它不生产依赖，而是外部依赖的 “缓存代理站”。通过它，既能解决外部仓库访问慢、不稳定的问题，又能统一依赖来源、保障构建一致性，是团队协作中 “提升效率、降低风险” 的关键配置。一次下载，全员复用

配置项	具体内容及说明
Name	`maven-proxy`（自定义仓库名称，用于标识该代理仓库）
Maven 2 版本策略	保持默认配置（无需额外设置，默认支持对外部仓库中 Releases 和 Snapshots 版本的代理）
Proxy - Remote Storage	远程仓库地址：`http://maven.aliyun.com/nexus/content/groups/public`
Storage - Blob store	选择 `maven-devops`（使用已创建的专用 Blob 存储，用于缓存从远程仓库下载的依赖）

4. 创建一个 group 类型的 maven 仓库。 ¶

Group 类型的 Maven 仓库是企业依赖管理的 “统一门户”，通过聚合多个仓库，既能简化项目配置、避免版本冲突，又能灵活扩展仓库结构。实际使用中，通常将其作为项目唯一的依赖来源地址，是 Nexus 仓库体系中 “提升协作效率” 的关键一环。

Group（仓库组）：叫 maven-group，是项目唯一的 “对接窗口”（项目只配置这个仓库组的地址），本身不存依赖，只负责 “调度”；
Proxy（代理仓库）：叫 proxy-maven，对接远程公共仓库（比如 Maven 中央仓库 https://repo1.maven.org/maven2/），核心能力是 “拉取远程依赖并缓存”；

配置项	具体内容及说明
仓库类型	Maven 2 Group（仓库组，用于聚合多个仓库为统一访问入口）
Version policy	Release（仓库存储的构件类型为正式发布版，即稳定版本的依赖）
Layout policy	Permissive（路径验证策略为宽松模式，对 Maven 构件或元数据路径的验证相对灵活，兼容更多非严格标准的路径）
Content Disposition	Inline（设置内容处置头为内联，允许内容在浏览器中内联显示，而非强制作为附件下载）
Blob store	maven-devops（用于存储仓库内容的 Blob 存储，管理该仓库组相关的文件存储）
Strict Content Type Validation	勾选（验证上传到该仓库的所有内容的 MIME 类型是否适合仓库格式，保障内容类型的规范性）
Member repositories	已加入的成员仓库有 `maven-local`、`maven-proxy`；可选的成员仓库包括 `maven-releases`、`maven-snapshots`、`maven-public`、`maven-central` 等，可根据需求选择并调整成员仓库的顺序（顺序影响依赖查找优先级）

（二）使用 nexus 构建 ¶

1. 配置私服地址 ¶

1. 复制 group 仓库地址 ¶

点击复制 group 仓库地址

2. 修改 mvn 配置 ¶

将项目编译依赖地址指向改成私服的仓库组配置，更改 maven 的配置 /usr/local/maven/conf/settings.xml的仓库地址。

    <mirror>
      <id>nexus-DevOps</id>
      <mirrorOf>*</mirrorOf>                                    # 劫持所有仓库
      <url>http://10.10.0.5:8081/repository/maven-group/</url>  # 私服地址
    </mirror>

2. 拉取项目编译 ¶

mvn clean && mvn install -e

查看构建过程确实用到了 maven-group	项目只对接仓库组，空仓库组让 Proxy 去远程拉依赖并缓存，Proxy 把缓存的依赖通过仓库组给项目

3. 拉取流程 ¶

流程拆解：项目首次拉取依赖的 5 步 “链路”

假设你现在执行 mvn clean install，项目需要下载 spring-boot-starter-web 这个依赖（本地仓库和 Nexus 都没有），整个流程就像 “项目找仓库组要东西，仓库组让 Proxy 去远程买，Proxy 买回来存好再给项目”，具体步骤如下：

1. 项目发起请求：“仓库组，给我 `spring-boot-starter-web`！” ¶

项目的 Maven 配置里，只写了仓库组 maven-group 的地址（比如 http://192.168.3.40:8081/repository/maven-group/）。当项目需要依赖时，不会直接找 Proxy 或远程仓库，而是只向仓库组发起请求：“我要 spring-boot-starter-web:2.7.18，你帮我找一下”。

2. 仓库组调度：“我这里没有，让 Proxy 去远程拉！” ¶

仓库组 maven-group 本身不存依赖，它的作用是 “管理成员仓库的优先级”（你之前配置时，把 proxy-maven 加进了仓库组）。仓库组先检查自己的 “成员仓库”：

首先看有没有 Hosted 私有仓库（比如之前的 maven-local），发现里面是空的；
再看 Proxy 仓库 proxy-maven，发现里面也没有这个依赖；
于是仓库组告诉 Proxy：“你去对接的远程仓库（Maven 中央仓库）把这个依赖拉回来”。

3. Proxy 拉取远程依赖：“远程仓库，给我寄 `spring-boot-starter-web`！” ¶

Proxy 仓库 proxy-maven 收到仓库组的指令后，会根据自己配置的 “远程仓库地址”（https://repo1.maven.org/maven2/），向 Maven 中央仓库发起请求： “我需要 spring-boot-starter-web:2.7.18，麻烦发给我”。

远程仓库（Maven 中央仓库）收到请求后，会把这个依赖的 pom 文件和 jar 包传给 Proxy 仓库。

4. Proxy 缓存依赖：“先存起来，下次不用再跑远路了！” ¶

Proxy 仓库拿到远程传来的 spring-boot-starter-web 依赖后，不会直接转发，而是先做一件关键的事 ——把依赖缓存到自己的 Blob 存储（比如你配置的 maven-use）里。这一步就是 Proxy 仓库的核心价值：“首次拉取，后续复用”—— 下次再有人要这个依赖，Proxy 直接从缓存里拿，不用再去远程仓库下载（省时间、省网络）。

5. 仓库组反馈给项目：“依赖来了，拿好！” ¶

Proxy 仓库缓存完成后，会把依赖传给仓库组 maven-group；仓库组再把依赖转发给发起请求的项目，项目拿到依赖后，就能继续完成编译、打包等操作。

6. 第二次拉取的变化（理解 “缓存” 的意义） ¶

如果下次另一个项目（或同一个项目再次构建）需要同样的 spring-boot-starter-web 依赖，流程会简化，跳过 “远程拉取” 步骤：

项目找仓库组要依赖；
仓库组找 Proxy 仓库；
Proxy 仓库发现自己已经缓存了这个依赖，直接传给仓库组；
仓库组再传给项目 —— 整个过程不用访问远程仓库，速度快很多。